emacs:帮我用 Flymake 和 csharp 解决这个自动加载排序问题

发布于 2024-10-03 00:36:39 字数 2247 浏览 3 评论 0原文

如何交付需要修补 Flymake 的模块,同时启动时间最短(=自动加载)并对用户的 emacs.el 影响最小?

我正在开发 Flymake-for-csharp 模块。它与 Flymake 配合使用,教它如何更灵活地使用 C# 代码文件。例如,flymake-for-csharp 不仅可以使用 makefile,还可以使用 .csproj 文件,或者可以直接调用 csc.exe。

该模块工作正常。我现在正在尝试使其正确自动加载。

这就是挑战。

为了定义哪些语言需要 Flymake,flymake.el 包含文件扩展名列表(.java、.cs、.c 等)以及每种语言的初始化和清理例程。默认的 Flymake.el 中有一个 C# 条目,但正如我所说,默认的 C# 行为不够灵活。为了使其更加灵活,我需要替换 Flymake alist 中的 C# 条目,以便它指向 Flymake-for-csharp 模块中新的 init/cleanup 逻辑。和我一起吗?

在运行时修补 alist 是没有问题的。看起来像这样:

  (let (elt
        (csharp-entry nil)
        (masks flymake-allowed-file-name-masks))

    ;; Find the existing C# entry
    (while (consp masks)
      (setq elt (car masks))
      (if (string= "\\.cs\\'" (car elt))
          (setq csharp-entry elt))
      (setq masks (cdr masks)))

    ;;  remove the original entry for C# ...
    (if csharp-entry
        (setq flymake-allowed-file-name-masks
              (delete csharp-entry flymake-allowed-file-name-masks)))

    ;; Now add a new entry for C#, with the custom init and cleanup methods.
    (setq flymake-allowed-file-name-masks
          (cons
           '("\\.cs\\'" flymake-for-csharp-init flymake-for-csharp-cleanup)
           flymake-allowed-file-name-masks)))

长期的解决方案是说服 Flymake 和 emacs 的作者接受目前 Flymake-for-csharp 中的逻辑。然后 alist 将获得更灵活的初始化/清理例程,并且 bob 是你的叔叔

但现在我希望 Flymake-for-csharp 能够与现有(内置)flymake.el 一起使用。这就是问题所在:如何使 Flymake-for-csharp 自动加载,同时仍然修补 alist?

理想情况下,我希望用户的 emacs.el 看起来像这样:

(autoload 'flymake-for-csharp-init "flymake-for-csharp" nil nil)

...可能有一个小的 (eval-after-load .. 部分。

但是你看,函数 flymake- for-csharp-init 仅在 Flymake alist 被修补以包含 C# 的新条目之后才会被调用。

有没有一种方法可以解决这种先有鸡还是先有蛋的情况


?想到的是使用(require 'flymake-for-csharp)代替autoload在flymake-for-csharp模块中,仅运行补丁逻辑,然后不知何故,对其余功能使用 autoload 是一个好主意吗?这需要我在两个不同的文件中提供 Flymake-for-csharp 吗?

我想到的另一种方法是使用 eval-after -load 在 Flymake.el 上,我可以提供补丁函数:

  • 只有当 Flymake 自动加载时才会起作用吗?当(外部)加载后评估时已经加载的模块?

  • 如何在不影响用户的 emacs.el 的情况下执行此操作?


总之, 如何交付需要修补 Flymake 的模块,同时启动时间最短(=自动加载)并对用户的 emacs.el 影响最小?

How can I deliver a module that requires patching flymake, with minimal startup time (=autoload) and minimal impact on the user's emacs.el?

I'm working on the flymake-for-csharp module. It works with flymake, teaches it how to be more flexible with C# code files. For example, instead of just using a makefile, flymake-for-csharp can also use a .csproj file, or can invoke csc.exe directly.

The module works fine. I am now trying to make it autoload properly.

here's the challenge.

To define which languages get flymake'd, flymake.el includes a list of file extensions (.java, .cs, .c, etc) along with the init and cleanup routines for each of those languages. There's an entry for C# in the default flymake.el, but as I said, the default C# behavior isn't flexible enough. To make it more flexible, I need to replace the C# entry in the flymake alist, so that it points to the new init/cleanup logic in the flymake-for-csharp module. Ya with me?

It's no problem patching the alist at runtime. It looks like this:

  (let (elt
        (csharp-entry nil)
        (masks flymake-allowed-file-name-masks))

    ;; Find the existing C# entry
    (while (consp masks)
      (setq elt (car masks))
      (if (string= "\\.cs\\'" (car elt))
          (setq csharp-entry elt))
      (setq masks (cdr masks)))

    ;;  remove the original entry for C# ...
    (if csharp-entry
        (setq flymake-allowed-file-name-masks
              (delete csharp-entry flymake-allowed-file-name-masks)))

    ;; Now add a new entry for C#, with the custom init and cleanup methods.
    (setq flymake-allowed-file-name-masks
          (cons
           '("\\.cs\\'" flymake-for-csharp-init flymake-for-csharp-cleanup)
           flymake-allowed-file-name-masks)))

The long term solution is to persuade the authors of flymake and emacs to accept the logic that is currently in flymake-for-csharp. Then the alist will get the more flexible init/cleanup routines and bob's your uncle.

But for now I want flymake-for-csharp to work with the existing (builtin) flymake.el. Therein lies the problem: how can I make the flymake-for-csharp autoload, while still patching the alist?

Ideally I'd like the user's emacs.el to look like this:

(autoload 'flymake-for-csharp-init "flymake-for-csharp" nil nil)

...with possibly a small (eval-after-load .. section.

But you see, the function flymake-for-csharp-init would be called only after the flymake alist is patched to include the new entry for C#.

Is there a way around this chicken-and-egg situation?


one approach I thought of was to use (require 'flymake-for-csharp) in lieu of autoload. Within that flymake-for-csharp module, run only the patch logic, and then use autoload, somehow, for the rest of the functions. Would this be a good idea? Would this require me to deliver flymake-for-csharp in 2 distinct files?

Another approach I thought of was to use an eval-after-load on flymake.el. In that I could provide the patch function. Couple questions with this:

  • Would that work only if flymake is autoloaded? What happens with the logic within an eval-after-load for a module that is already loaded when the (outer) eval-after-load is eval'd?

  • how would I do this without impacting the user's emacs.el?


In summary,
How can I deliver a module that requires patching flymake, with minimal startup time (=autoload) and minimal impact on the user's emacs.el?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

东风软 2024-10-10 00:36:39

如果我理解正确,让用户将其添加到他们的 .emacs 中可以解决问题:

;;;###autoload
(eval-after-load "flymake" '(code-that-patches-flymake-allowed-file-name-masks))
(autoload 'flymake-for-csharp-init "flymake-for-csharp" nil nil)

现在,如果您与使用您的包的人一起工作,您可以使用 loaddefs.el 技巧让用户自动加载此代码,方法是将包中 eval-after-load 行之前的 ;;;###autoload 注释,然后重建 loaddefs.el 文件。

但是,如果您希望找到一种在互联网上通用的解决方案,则需要用户在其 .emacs 中包含这两行。


对您的清理代码的评论,我相信它可以简化为:

(let ((csharpentry (assoc "\\.cs\\'" flymake-allowed-file-name-masks)))
  (when csharpentry
    (setcdr csharpentry '(flymake-for-csharp-init flymake-for-csharp-cleanup))))

If I understand correctly, having the user add this to their .emacs would solve the problem:

;;;###autoload
(eval-after-load "flymake" '(code-that-patches-flymake-allowed-file-name-masks))
(autoload 'flymake-for-csharp-init "flymake-for-csharp" nil nil)

Now, if you work with the folks using your package, you can use the loaddefs.el trick to get this code automatically loaded by the user by putting the ;;;###autoload comment right before the eval-after-load line in your package, and then rebuild the loaddefs.el file.

But, if you're hoping for a solution for general usage in the internets, you need the user to have both lines in their .emacs.


A comment on your cleanup code, I believe it can be simplified to:

(let ((csharpentry (assoc "\\.cs\\'" flymake-allowed-file-name-masks)))
  (when csharpentry
    (setcdr csharpentry '(flymake-for-csharp-init flymake-for-csharp-cleanup))))
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文