Hi, This is a fairly small point and was easy for me to locally address, and that in itself may be valuable in sharing, but I wondered if it would be worth putting a change behind a defcustom option, or depending on how this works with other completion frameworks, changing it altogether? The "B"
On Friday, 2020-04-24 at 15:46:20 -04, Ori wrote: > Hi, > > This is a fairly small point and was easy for me to locally address, and > that in itself may be valuable in sharing, but I wondered if it would be > worth putting a change behind a defcustom option, or depending on how this > works with
Starting with Emacs 27 the old `cl' implementation is finally considered obsolete. Previously its use was strongly discouraged at run-time but one was still allowed to use it at compile-time. For the most part the transition is very simple and boils down to adding the "cl-" prefix to some
As recommended by the byte-compiler. --- test/emacs-attachment-warnings.el | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/test/emacs-attachment-warnings.el b/test/emacs-attachment-warnings.el index a23692d7..8f4918ef 100644 ---
--- test/Makefile.local | 4 1 file changed, 4 insertions(+) diff --git a/test/Makefile.local b/test/Makefile.local index 47244e8f..3c043717 100644 --- a/test/Makefile.local +++ b/test/Makefile.local @@ -78,6 +78,10 @@ endif check: test +compile-elisp-tests: + $(EMACS) --batch -L
I have fixed the remaining issues and added two small commits. See v3. > Or of course you can/should get the tests running locally. The problem was that there are incompatible changes in Emacs 27. I am using Emacs 26 for the time being but will look into these breaking changes later. The
This implements the notmuch-tree version of notmuch-show-filter-thread and binds it to the L key. Signed-off-by: William Casarin --- emacs/notmuch-tree.el | 9 + 1 file changed, 9 insertions(+) diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el index e5c23de2..8f7738d7 100644
Hi David, Keegan Carruthers-Smith posted a patch with a suggested change for this in id:email@example.com. Could you try that and see if it addresses your concerns? That patch is now in HEAD, but I presume not yet in a release. Yes that patch fixes the issue