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?
