Question

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?

Answer 1

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))))