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.
The notmuch.c main program now uses GMime directly rather than using
these functions, and I'd rather not export any functions unless we
have good evidence that the functions are necessary.
We had originally copied this function in at a time when notmuch
wasn't actually depending on the GMime library. Now that it does,
we might as well call the function that exists there rather
than having a private copy of it.
This is *not* based on autoconf. In fact, this doesn't actually
configure anything, (one can compile notmuch directly with just
"make" without running configure if the dependencies are all
satisfied).
The only thing that this configure script does is to check for the
presence of the various dependencies and provide some guidance to
the user if they are not all available.
I had noticed several times earlier that having a talloc context
passed in would make things more convenient. I'm not exercising
that convenience yet, but the context is there now, (and there's
one fewer item on our TODO list).
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.
Doesn't really do anything so far other than mark the buffer read-
only. This does have the benefit of giving us our own name rather
than "Compilation" for the mode.
The timestamp stuff we'll want to do soon, since it's a database
change, (though not a major one---at worst a handful of stale
timestamp documents would be left in the database).
We were aware of this bug when we wrote the function, (that a date
six days in the past would be treated as the "Friday" or as the
"Oct. 23" case depending on whether its time was before or after
the current time today). We thought it wouldn't be a problem, but
in practice it is. In scanning search results with this output,
the transition between formats makes it look like a day boundary,
(so it would be easy to mistakenly think "Oct. 23" is Thursday).
Fix this to avoid confusion, (still being careful to never print
"Thursday" for a date 7 days in the past when today is Thursday).
