| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
| |
Otherwise, try to keep point in the same place, (such as when the
current thread has been archived away).
|
| |
|
|
|
| |
This will allow for updates when a separate process (say, a notmuch-
show buffer), has archived messages.
|
| |
|
|
|
| |
Of course, technically, we're removing the "unread" tag, but you
get the idea. :-)
|
| |
|
|
|
| |
The user can make these visible again by pressing 'c' or 's',
(though we'd like to move to direct manipulation instead soon).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
The display of the header can be toggled with the 'h' key.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This is much more convenient for reading the messages, and happens
to match the behavior of sup.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Also, take care to remove a final blank line to avoid the point
going beyond the last thread in the buffer.
|
| |
|
|
| |
Also add 'q' and 'x' keybindings to kill the current buffer.
|
| |
|
|
| |
One more baby step toward something that's pleasant to use.
|
| |
|
|
|
| |
There's no undo still, but at least you can see what you are doing
now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
inbox tag)
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
)
|
| |
|
|
| |
Just looks a little neater that way.
|
| |
|
|
|
| |
It's remarkable how little code we need for a very functional GUI
here. I think we're doing something right.
|
| |
|
|
|
| |
All we have here so far is 'n' and 'p' for going to next and
previous lines respectively.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
This allows for entering a query string interactively.
|
| |
|
|
|
|
| |
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.
|
|
|
Also add the copyright and licensing blurb.
|
Carl Worth