Re: [PATCH 2/2] emacs: Allow tagging regions in notmuch-tree

Subject: Re: [PATCH 2/2] emacs: Allow tagging regions in notmuch-tree

Date: Sat, 25 May 2019 10:42:56 -0300

To: Pierre Neidhardt,


From: David Bremner

Pierre Neidhardt <> writes:

> David Bremner <> writes:
>>> --8<---------------cut here---------------start------------->8---
>>>> guix environment notmuch -- /home/ambrevar/.local/share/emacs/site-lisp/notmuch/test/
>>> guix environment: error: execlp: No such file or directory: "/home/ambrevar/.local/share/emacs/site-lisp/notmuch/test/"
>>> --8<---------------cut here---------------end--------------->8---
>> I can't really help you with Guix, but I suggest setting up some
>> environment where you can run things in an interactive shell.
>> In particular that error seems to be claiming the test file doesn't
>> exist, which would be easy to debug in an interactive shell.
> Yup, that's what I did with "guix environment notmuch": it sets up a
> build environment (and an interactive shell) for notmuch.  And I really
> wonder why it can't find the file, it's there in the interactive shell.
> It's possible that the error message is a red herring though, I'll look
> into it.

I case it helps, attached is the output from

% cd test && ./

Note that the tests do need to be run from that directory.

The two new tests that actually use emacs are failing with output:

*ERROR*: Wrong number of arguments: (1 . 1), 0

Running the tests interactively (just eval testl-lib.el first) suggests
that is output from set-mark-command (in emacs 26.1, it demands at least
one argument).

test.out (application/octet-stream)
> So would you like me to patch the namespacing along with these changes
> or leave it for another patch?

I'd leave namespacing of existing code for a new series if you're
motivated to work on that. For your new code, I think it makes most
sense to have it in the patch that introduces the code.

>> I assume you are not using git-send-email because it's difficult for
>> you; it's not that a big of a deal, although we do prefer series
>> generated git-send-email for reviewing.
> I'm using git-send-email on a regular basis, no problem with that.  (I
> wonder why you would think it's difficult for me :p)

My mistake, I assume everyone read ;).

> git-send-email comes with different workflows though, I'm not sure which
> one Notmuch follows.  Do you prefer versioned patch series
> (e.g. [PATCHv2], etc.) or patch updates sent with
> "--in-reply-to=<message-id-of-the-last-email>"?

For series, probably the former. For single patches, or updates to the
single patches in the series, the latter.


notmuch mailing list