Avoding these is nicer to users, text editors, and our poor little
notmuch.el code itself that would get confused when seeing a copy of
itself in email. (Of course, we should still fix that bug, but this
workaround is good nonetheless.)
This patch add notmuch-search-hook that gets run when we
after displaying search results
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc:Keith Packard <keithp@keithp.com>
I created the notmuch-show-hook precisely so I could add these two
options, but I suspect most people will want them, so I just made them
the default. If you don't want them, you can use remove-hook to get
rid of this.
Signed-off-by: Keith Packard <keithp@keithp.com>
I wanted to enable got-address-mode and visual-line-mode in my show
windows to make messages easier to read and URLs easier to
follow. This hook allows the user to run arbitrary code each time a
message is shown.
Signed-off-by: Keith Packard <keithp@keithp.com>
This is what most people want for a _search_ command. It's often
different for actually reading mail in an inbox, (where it makes more
sense to have results displayed in chronological order), but in such a
case, ther user is likely using an interface that can simply pass the
--sort=oldest-first option to "notmuch search".
Here we're also change the sort enum from NOTMUCH_SORT_DATE and
NOTMUCH_SORT_DATE_REVERSE to NOTMUCH_SORT_OLDEST_FIRST and
NOTMUCH_SORT_NEWEST_FIRST. Similarly we replace the --reverse option
to "notmuch search" with two options: --sort=oldest-first and
--sort=newest-first.
Finally, these changes are all tracked in the emacs interface, (which
has no change in its behavior).
The documentation for 'next-line' suggests that 'forward-line' is a
better choice for non-interactive usage. That appears to be the case
here; using next-line caused emacs to spin forever for me.
Signed-off-by: Keith Packard <keithp@keithp.com>
This is the default separator used by mailman, so there's a lot of
clutter in thread displays without this. Also, we not provide a nice
variable to the user (notmuch-show-signature-regexp) for configuring
this.
I think there's a GMime bug that we're getting parts decoded without a
final newline (the encoded parts seem to have them just fine). We can
workaround the bug easily enough by finding a part-closing delimiter
that is not at the beginning of a line, and if so, just insert a
newline.
Without this, the one-line-summary of the next message would continue
on the same line as the last line of the previous message, (and this
would often happen for mailing-list messages where mailman would add
an extra part for its signature block).
This makes it much easier to actually read the subject lines.
The user can set notmuch-search-authors-width to control the width of
the column.
Two possible ideas for improving this support further:
1. Make the excess authors invisible instead of removing them from
the buffer, (which means that isearch could still find them).
2. Have the user variable control a percentage of the window width
rather than being a fixed number of columns.
Now that we're actually adding text to the buffer for the indentation,
our old aproach of using positions to record regions to manipulate is
now longer correct. Fortunately, it's easy to switch from positions to
markers which are robust, (just call point-marker instead of point and
all relevant functions accept markers as well as points).
I also finally fixed the bug where the text "[6 line signature]" we
display was causing the one-line-summary of the next message to be on
its same line rather than at the beginning of the next line where it
belongs.
Currently just supports viewing all MIME parts in the message. There's
not yet support for selecting and viewing individual parts, but that
should be easy to add from here, (now that we've found
mm-display-parts to do all the heavy lifting).
This gives us two different default search orders: The inbox view that
comes up from "M-x notmuch" is sorted in chronological order (oldest
threads first). A new global search "M-x notmuch-search" will instead
be in reverse chronological order (newest threads first).
Any filtered searches retain the sort order of the search being
filtered.
There's not yet any interface for changing the sort order of a search
after it is constructed.
I wrote these originally jsut for debugging. They've never been hooked
up to any keybinding and the existing "M-x visible-mode" does what's
needed anyway.
This way we get to take advantage of the configuration of the user's
email addresses in notmuch, (rather than expecting the user to
configure all of their email addresses in message mode as well).
We were just starting to get "notmuch reply" into shape in order to
provide the needed functionality here, but then I realized that the
message-reply function built into emacs is already more functional,
(at least for the case of replying to a single message).
Previously, when selecting a thread to view from the search buffer, we
would advance the point by one line before showing the thread, (so
that it would be ready to show the next thread once the user was done
with the current thread). This was annoying when the user temporarily
exited the thread view, (because the "wrong" thread was then selected
in the search view).
We get a more consistent experience by waiting to advance until the
user has finished viewing one thread and is ready to view the next.
The recent change of the hidden thread-ID syntax caused this message
to instead be replaced with a cryptic "search failed" error and an
internal regular expression. Put our nice message back.
This is in place now citations and signatures. We'll still need to
add something else for hidden messages (those that are already
read and hidden away).
The more general command is more consistent, and more useful.
We also fix "notmuch search" to output copy-and-pasteable search terms
for the thread with "thread:" prepended already. Similarly, the
message-ID in the output of "notmuch show" is also now printed as a
valid search term, ("id:<message-id>" rather than "ID: <message-id>").
Naturally, the emacs code is also changed to track these changes.
The magic space bar is nice, but sometimes there's a message with a
long attachment that I just want to skip, but still consider the
message marked as read.
I had implemented this intentionally originally, thinking that it
would be important to see the last message scroll all the way off
screen before the next press of the magic space bar would go and
archive away the whole thread.
But in practice, that just turns out to be annoying, (especially for a
long sequence of single-message threads where the space bar has to be
pressed twice for every one). It's actually quite easy to know if it's
"safe" to press the space bar expecting just a scroll instead of an
archive by simply looking down and seeing if the current window is
full.
And as for the total lack of undo with all of this, I'm getting by by
simply using x to get back to the search view, and then going back
into the thread of interest.
More magic for the magic space bar: If a thread is entirely open,
(such as when viewing an old thread where every message is read), the
space bar now visits each message in turn (rather than skipping all of
the unread messages).
Otherwise known as "Backspace" on keyboards in the real, (rather than
emacs), world. This will go by screenfuls for long messages, and
message by message for short messages. So it does the reverse of the
magic space bar, (but without reversing any tag-changing magic that
the magic space bar might have done).
Chances are, a signature above a certain threshold isn't just a
signature, (for example, it could be an encrypted messages tacked onto
the end of the file, or could be any sort of PS.)
We add a new variable, notmuch-show-signature-lines-max that can be
used to configure the threshold, (set to 6 by default for now).
I noticed that these functions would sometimes leave point on an
invisible character[*]. The problem would be that point would appear
to be on a particular message, but adding or removing a tag would
actually add/remove a tag from the *previous* message.
Fix the C-n and C-p keybindings at least to call the underlying
command and then advance to a visible character. We set this-command
in our overrides so that the temporary-goal-column feature still
works.
[*] The documentation says that command loop is supposed to move point
outside of any invisible region when a command exits. But apparently
not.
Clearly some recent code was very fragile, which I noticed in that the
space bar would no longer scroll a long message if it was the only
message in a thread.
This resulted in a lot of churn, but hopefully things are more robust
now, (for example by using new predicates like
notmuch-show-last-message-p rather than doing heuristics based on
(eobp) or (window-end)).
As usual, the presence of invisible characters complicates the task of
making this stuff robust.
With the recent change of showing the first unread message, we would
scroll down to the end of the buffer if all messages were already
read. This would confusingly show nothing visible in the window.
Instead, detect this case and move to the beginning of the buffer.
The magic of the space bar is all about unread messages, so there's no
reason for it to advance to messages that have already been read.
Similarly, we now remove any magic from (n)ext so that it simply
advances to the next message without marking anything read, (which
makes it symmetrical with (p)revious).
This allows for pleasant termination of the "show next thread" magic
in notmuch-show mode. Now, it will terminate and show the
notmuch-search results rather than continually displaying the last
thread over and over.
This is implemented by stashing away the parent notmuch-search buffer
into a variable within the notmuch-show buffer. Then, when magic space
bar triggers an archive of the current thread, it switches to the parent
search buffer and shows the next thread.
The approach here is to move the optimization from mark-read to the
more general remove-tag. Namely, don't call out to a "notmuch tag"
command to remove a tag that's not there already.
Currently this will either advance by screenfuls, or to the next
message if it's already within a screenful, and will mark each message
read as it is left.
It doesn't yet complete the magic by archiving the messages nor by
advancing to the next thread in the search.
Now, if the user has manually moved point to somewhere within a
message, executing the previous-message command onece will rewind
point only to the beginning of the current message. Previously this
would go back to the previous message, (which the user can now do
easily and naturally by simply executing the command one more time).
Before this just brought the current line to the top of the
window. Now it actually moves to the beginning of the current message.
This is built on a much more solid foundation now with a function to
move to the summary-line of the current message, and then moving from
there.
These now provide a summary of the most useful features/bindings
as well as a complete printout of the relevant mode maps to show
all available keybindings.
This is the command in notmuch-search mode and it's cer convenient
for it to advance to the next line there. (It would be even more
convenient if it didn't also take forever, but as mentioned before
that's an issue we'll need to fix in Xapian.)
We turn on the scroll-preserve-screen-position option which seems
like what's desired here, (though that's not what I normally use
when editing files---but I think scrolling through a list of email
threads is different).
I had put these in here since I had originally planned to copy
liberally from the body of the implementation of 'compile in order
to get process output into a buffer. But once I found call-process
in the documentation of emacs, that was all I needed.
And all the code I've written since has been entirely my own with
just the help of emacs documentation.
This is our first race-free implementation of archive-thread! It
acts only on the messages explcitly contained in the buffer, not
on an entire thread ID, so it's safe in the face of new messages
have been delivered for this thread since the view was made.
This optimization wouldn't be necessary if we had a nice fast "notmuch
tag" command. But since it's currently fairly slow, (see Xapian defect
250: http://trac.xapian.org/ticket/250), we're willing to take some
extra care to avoid calling "notmuch tag" unnecessarily.
I previously had a hack that special-cased the "unread" tag and
printed it on the same line as the message ID. But now that we are
printing all tags at the end of the one-line summary we don't need
this anymore. Get rid of it, and just read "unread" from the list of
tags just like any other tag.
This is in notmuch-show mode rather than in notmuch-search mode,
(where we had + and - working already). This gives the same visual
feedback as in notmuch-search-mode, (the tags are manipulated first in
the database and then the list of tags in the buffer is updated).
Also hide all markers.
From here, all we really need for legibility is the following:
* Hide away citations and signatures
* Call out the one-line summary some way, (larger font size?)
* Add nesting for replies
We were previously using things like "%message{" which were not
guaranteed to never appear in an email message. Using a control
character (^L or '\f' instead of '%') gives us better assurance that
our delimiter doesn't show up in an original email message.
This still isn't entirely safe since we're decoding encoded text in
the body of the email message so almost all bets are off really.
Almost starting to get usable now. Still need to make it mark messages
as they are read, (by removing the unread tag), and selectively hiding
the full header.
These have keybindings of '+', '-', and 'a'. The bug they have so
far is lack of visual feedback for their effect, and lack of undo.
(Also the fact that adding or removing a single tag for a thread
takes way too long--but that's as a Xapian issue as discussed here:
replace_document should make minimal changes to database file
http://trac.xapian.org/ticket/250
)
We now get the point staying right at the top where we want it.
We also don't get any extraneous noise about "Process notmuch
completed" or anything like that. Just the output in a read-only
buffer.
Compilation mode does a bunch of things that we don't want. Instead
of trying to tear it down to what we want, let's start at the other
end and build up only things that we really want.
I'm using that file as my reference here, so I'm likely to end up
copying some code here or there. Might as well be safe and just
copy the copyright statement.
