| Age | Commit message (Collapse) | Author |
|---|
|
A recent "notmuch restore" command took *forever* for me. Obviously,
we need to fix the underlying performance bug in Xapian, but in the
meantime, a progress indicator would help.
|
|
This was just some extra noise printed when requesting a non-default
mail directory itneractively.
|
|
We'll use this eventually for properly nesting messages in the output
of "notmuch show", etc.
|
|
Otherwise, it would just fail if you hadn't run "make" already.
|
|
I recently added a print of the subject line for use as part of a
two-line summary in the emacs client. But of course, the subject was
already being printed on the next line. So I didn't really need to add
anything, I could have just stopped hiding what was already
printed. Anyway, we now avoid printing it twice in a row.
|
|
I'd fixed this earlier when I had a private copy of GMime's
date-parsing code, but I lost the fix when I recently switched to
calling the GMime function.
|
|
And change the display code in emacs to display the one-line summary
in inverse video.
|
|
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).
|
|
This is useful for when the rest of the thread is visible on screen so
the user really has read the rest of it.
|
|
It would be nice to have this documentation live in a single place,
but for now, this is what we get.
|
|
I've been using these for a long time, but I had neglected to document
them until now.
|
|
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.
|
|
With the obvious keybinding.
|
|
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).
|
|
This takes advantage of the new filename output just added to "notmuch
show".
|
|
This will allow a client using "notmuch show" to directly open the
filename and do whatever it wants with it.
|
|
Make at least some attempt to distinguish internal variables from
those that the user is expected to fiddle with.
|
|
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).
|
|
Previously, it was reporting that all signatures were 0 lines.
|
|
Presumably the user is trying to view this thread for a reason, so
it's better to actually show *something* rather than just the summary
lines.
|
|
We were inadvertently calling g_object_unref on a wild pointer leading
to the following error message:
GLib-GObject-CRITICAL **: g_object_unref: assertion
`G_IS_OBJECT (object)' failed
Now, why glib doesn't abort on critical errors, I'll never understand.
|
|
If there's nothing to scroll but we're not yet on the first or last
message then move point to that message.
|
|
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 is important for when a new message is delivered to an existing
enormous thread.
|
|
We need an easier way to detect when we're done with the last message
so taking advantage of the end-of-buffer position helps here.
|
|
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.
|
|
If I explicitly hit the 'a' key before reading the whole thread, I
still want to advance to the next thread in my search.
|
|
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 idea here is that after viewing the thread, when we come back to
this buffer we'll be all ready to view 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.
|
|
Next all it needs to do is kill the buffer and show the next thread.
|
|
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.
|
|
Previously, unhinding a read message would still show all the citations
in that message without an explicit command to make them visible. Fix.
|
|
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.)
|
|
This is a convenience function to avoid having to type "tag:" with
the (f)ilter command.
|
|
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.
|
|
I'm definitely more comfortable with the add-to-invisibility-spec
now than I was when I first wrote these functions, (which weren't
working at all).
|
|
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.
|
