David Bremner <david@tethera.net> writes: > Mark Walters <markwalters1009@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. :-)"