Having actually implemented this, I realized that my
initial approach of providing a function to configure
a button was wrong. Instead I've replaced that with
button types. This then makes it possible to provide
the fully expanded view when all threads in a message
are unread.
It also has the potential to allow global-expansion functions
if that is desireable
This is the same as with citations and signatures.
I used an ellipsis here for the invisible region, which
I think make it more obvious that there are extra headers.
MH-e used this for extra long To/CC headers.
Folder mode takes a (user-configurable) list of search patterns and
produces a list of those patterns and the count of messages that they
match. When an entry in this list is selected, a search window with
the defined search is opened. The set of folders is defined as a
list, each element contains the name of the folder and the query string
to count.
Signed-off-by: Keith Packard <keithp@keithp.com>
Selecting text in the search view isn't all that useful, so instead,
make mouse-1 clicks actually show the thread you click on. It's almost
like direct manipulation or something.
Signed-off-by: Keith Packard <keithp@keithp.com>
When you compose a new message, message mode carefully inserts your
mail signature at the bottom of the message; as notmuch constructs the
reply all by itself, this doesn't happen then. Use the message mode
function 'message-insert-signature' to add that to reply buffers.
Signed-off-by: Keith Packard <keithp@keithp.com>
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.
