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. Quoting from the package description: ,---- | This is a forward compatibility package, which provides (a subset of) the | features of the cl-lib package introduced in Emacs-24.3, for use on | previous emacsen. | | Make sure this is installed *late* in your `load-path`, i.e. after Emacs's | built-in .../lisp/emacs-lisp directory, so that if/when you upgrade to | Emacs-24.3, the built-in version of the file will take precedence, otherwise | you could get into trouble (although we try to hack our way around the | problem in case it happens). `---- > (As an aside if we do that do we need to include any copyright notice or > similar? -- maybe notmuch-lib.el could include notmuch-compat.el which > would contain all the compatability functions?) We should definitely preserve copyright information (the licensing is the same, so no problem there) >> The only other package I have non-trivial experience working with is >> Gnus, and the practice there was to place portability interfaces in the >> gnus- namespace, and refrain from calling the "native" interfaces >> directly. > > I think this would introduce a lot of clutter, so I would prefer not to > go that route. I don't have strong opinions about that, but note that we're talking about (currently) 5 lines of code. d