pick was meant to use the same mini-buffer history but this failed
because the interactive definition took place before the use search
mini-buffer history part. Remove the interactive prompt to ensure the
correct history is used.
This patch fixes three issues with "notmuch-mutt tag":
1. The message_id was not shell quoted.
Thanks to Jason Miller for the bug report and patch.
2. The tags passed into tag_action() were not being properly quoted.
The "join before shell_quote" was combining multiple tags into a
single argument to notmuch tag: '+one -two -three' instead of
'+one' '-two' '-three'.
3. A "--" was added between the tags and search-term as shown in the
current notmuch-tag man page.
Thanks to Tomi Ollila for suggesting the simple fix of using
the list form of system(), which bypasses the shell.
Change notmuch-mutt to use the new --duplicate=1 flag for duplicate
removal. This will remove duplicates based on message-id at the
notmuch level. Previously we were using fdupes or generating sha sums
after the search.
This version will be faster, but will enable the possibility of hiding
search results due to accidental/malicious duplicate message-ids.
This variable is essentially unused: it was only used for making sure
it itself got reset after a refresh of the buffer.
It did this by passing an unnecessary argument to notmuch-pick-worker
so remove that too.
This adds functions to go to the previous or next thread to
pick. Prev-thread behaves similarly to prev-message in show: if you
are on the top line of a thread it will go to the top of the previous
thread, otherwise it will go to the top of the current thread. Next
thread will always go to the top of the next thread (or the end of
buffer). These are bound to "M-p" and "M-n" by default (matching the
bindings in show).
Previously pick had no actions based on the entire thread: this adds
some. Note in this version '*' is bound to `tag thread' which is not
consistent with search or show. However it still might be the most
natural thing (as it is similar to running * in the show pane).
Previously notmuch-pick had no thread based functionality. This adds a
macro to iterate through all messages in a thread. To simplify this it
adds a text-property marker to the first message of each thread.
Previously pick had the option of using an async parser like search or
a sync parser like show. The async parser has always been the default
and it seems fine so we can remove the sync one and the corresponding
defcustom.
This makes tab move to next button in the message pane and binds
button activate (in message pane) to "e". This means that is easy to
toggle hidden parts or hidden citations etc in the message pane.
We will want to be able to activate buttons not in the current
buffer (ie in the message pane) so it is helpful to have a way of
activating a button without signalling error if there is no button.
These functions all now work straight from their notmuch-show
implementation so link them in.
Stash functionality was one of the key missing things in notmuch-pick.
We can use the attachment functions straight from
notmuch-show. notmuch-show-view-all-mime-parts might be deprecated so
we either want to undeprecate it or not have this binding.
We override notmuch-show-get-prop so that many of the show functions
can be used in notmuch-pick without modification. The main use is that
it means notmuch-show-get-message-id `works' in pick. Thus we get all
the stash functions and several other `for free' in pick.
The variable notmuch-pick-message-buffer should be buffer local but
instead notmuch-pick-message-buffer-name (a non-existent variable) was
made buffer local.
The function notmuch-pick-refresh-result (used to update tag changes)
was not quite correct: sometimes it got the choice between the subject
and " ..." wrong. This was always true but the new code often calls
this (when opening a message in the message pane to remove the unread
tag) while the async pick process is still running and this caused
mistakes which made the tests fail.
Thus we store the previous subject with the message.
This function was a horrible hack (sleeping while waiting for the
correct message). The new target code can just open the message in the
message window when it arrives.
Previously pick removed the unread tag from its tag display: since the
tag change is now customisable use the customised variable.
This only affected the tags displayed, not the tags in the database as
notmuch-show (in the view pane) did the actual tag changes.
Previously pick set a prefix argument prior to calling show in the
message pane to tell show to only show matching messages. This sets
notmuch-show-only-matching-messages instead which is much cleaner and
will work even if the user has configured show to default to showing
only matching messages.
This adds a target message for pick which it will jump to when (if) it
appears. It adds the target to notmuch-pick-from-show-current-query so
that pick goes straight to the message that was current in the show
view and it adds target to notmuch-pick-refresh-view so that the
current message is preserved.
Pick keeps point roughly at the top of the buffer while inserting
messages at the end as they come in (from the async
parser). Previously the save-excursion to do this was done once for
each thread inserted: now it is done for each individual message.
The advantage is that the message insertion code can decide where to
leave point. In the next patch point will be left on the target message.
Note notmuch-pick-insert-msg is unchanged as that is used by the tag
display update code.
Details:
- $pipe_decode is turned off, to prevent message-id from being
filtered out by "ignore" settings in the muttrc.
- Original values for $pipe_decode and $wait_key are saved and restored.
- The macros, being much longer now, are line wrapped for improved
readability.
On Thu, Feb 14, 2013 at 12:36:58AM +0100, Profpatsch wrote:
> On 13-02-13 02:35pm, Kevin J. McCarthy wrote:
> > A more likely idea is to check whether you have $pipe_decode set.
>
> BRILLIANT!
> So much for copying a basic rc from someone else.
> Of course, that was it and I’m officially an idiot.
Neat, thanks Kevin for debugging the issue down to $pipe_decode (which
I've never used, mutt never stops to amaze me :-)).
> And apparently Mail::Internet errors out if there is no Message-ID.
> (Which mentioned in the docs at CPAN…)
>
> Mystery solved.
Right, but still a more graceful failure model would be nice.
Please find attached a patch that in such cases should 1) give a
supposedly nice error message explaining what's going on and 2) empty
the results dir to avoid showing you unrelated results. It works for me.
But extra checking never hurts, in particular for the tag action, which
I don't personally use.
I guess it would also be nice to actually disable $pipe_decode in the
relevant Mutt macros, but I'm not sure about to do that without
interfering with user desired configuration. Kevin: do you know if there
is a common Mutt trick to store the value of a variable before changing
it, and restoring it a posteriori? More isolation for this kind of
things in Mutt would definitely be welcome...
Cheers.
--
Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
From b67ab95855ce7d279d8c0b3ddcbc20e679afc70b Mon Sep 17 00:00:00 2001
From: Stefano Zacchiroli <zack@upsilon.cc>
Date: Thu, 14 Feb 2013 09:31:37 +0100
Subject: [PATCH] notmuch-mutt: more graceful handling of missing Message-Id
errors
in particular:
- the "thread" action would print an error and empty results dir
- the "tag action would print an error
As discussed in id:871udhcmks.fsf@zancas.localnet, notmuch-vim doesn't
really meet the standards of the CLI, emacs interface, or python
bindings in terms of being well maintained.
There seems to be consensus to use presence in contrib as
documentation of limited support by the notmuch developers; in fact
nmbug is pretty integrated into our current development process, so
devel seems more appropriate.
