emacs:帮我用 Flymake 和 csharp 解决这个自动加载排序问题
如何交付需要修补 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果我理解正确,让用户将其添加到他们的
.emacs
中可以解决问题:现在,如果您与使用您的包的人一起工作,您可以使用 loaddefs.el 技巧让用户自动加载此代码,方法是将包中
eval-after-load
行之前的;;;###autoload
注释,然后重建loaddefs.el
文件。但是,如果您希望找到一种在互联网上通用的解决方案,则需要用户在其
.emacs
中包含这两行。对您的清理代码的评论,我相信它可以简化为:
If I understand correctly, having the user add this to their
.emacs
would solve the problem: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 theeval-after-load
line in your package, and then rebuild theloaddefs.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: