[PATCH] emacs: add compatability functions for emacs 23

Matt Armstrong marmstrong at google.com
Thu Oct 27 10:02:07 PDT 2016


David Bremner <david at tethera.net> writes:

> Mark Walters <markwalters1009 at gmail.com> writes:
>
>> This is a good point. I think I don't mind too much if they do -- they
>> should see it is provided by notmuch-lib if they do describe-function
>> etc. But maybe bremner would like to comment?
>>
>> However, maybe other packages are doing the same. Thus I think we should
>> not put in a cut down version of read-char-choice but just include the
>> whole command from the emacs24 source. That way if any other package is
>> doing the same load order doesn't matter -- we don't stomp on them and
>> they don't stomp on us.
>
> There is a sort of precedent with the package cl-lib.el.  Of course it's
> not exactly the same since it's mainly providing new names for
> functionality that already existed.

I'm obviously in no place to object strongly, but I like this approach
less the more I think about it.  I've had similar things come back to
bite me too many times in the past.

Here I find Steve Purcell raising the same concern:

https://github.com/melpa/melpa/pull/1748#issuecomment-45082451
https://github.com/swift-emacs/swift-mode/issues/10

I'm concerned entirely about surprises.  Folks don't expect packages to
provide future compatibility functions.  Imagine using Emacs 23 and,
maybe because you're copy/paste hacking your personal elisp, you come to
use setq-local.  Or perhaps you use some *other* add-on that uses
setq-local but makes no effort to support Emacs 23.  Then you decide to
move (require 'notmuch) a little lower in your .emacs and *boom*, your
config is broken.

So I'd rather see this kind of thing:

;; TODO: remove and use setq-local directly when Emacs 23 support is dropped.
(if (fboundp 'setq-local)
    (defalias 'notmuch-setq-local 'setq-local)
  (defmacro notmuch-setq-local (var val)
    "Set variable VAR to value VAL in current buffer."
    `(set (make-local-variable ',var) ,val)))

Then just call notmuch-setq-local from notmuch code.  That follows the
expected convention that packages add symbols under their own namespace.

But, as far as prior art, we have examples of other packages patching in
a setq-local:

https://github.com/flycheck/flycheck/commit/b19bd4fdf118c55a96d72b2b3c034a0393cfcae2
https://github.com/fxbois/web-mode/issues/438

...and I have to agree with Steve when he says "This isn't the most
egregious example, though. :-)"


More information about the notmuch mailing list