I happen to have a lot of saved searches that are variants of the
tag:inbox search, (such as "tag:inbox and tag:notmuch"). The logic for
these was always matching inbox first, resulting in "[ inbox ] and
tag:notmuch" rather than "notmuch" as desired.
Anchor the regular expression on both ends to make it look harder for
the better match.
We are asserting that the new notmuch-hello implementation, (available
by just calling `notmuch') is just as easy to use as the old
notmuch-folder. So let's remove what's now a largely redundant
implementation.
To make this transition easier, we are still supporting the
notmuch-folders variable name, and we still provide `notmuch-folder'
as an alias which can be invoked to get the new notmuch-hello
functionality.
Previously, this was calling into a notmuch-folder-count
function. Only, everything related to notmuch-folder is about to go
away, so lets have notmuch-hello define its own function
(notmuch-saved-search-count) for this purpose.
We use this function to abstract away the common 3-step process for
looking for a value for the saved-searches variable:
1. Look at the notmuch-saved-searches variable itself
2. Look at the notmuch-folders vaiable
3. Use a default value
We were already using this logic (open-coded) in notmuch-hello, but
notmuch.el was accessing notmuch-folders directly for the clever name
selection of search buffers.
I'm planning to rip out the notmuch-folder-mode completely. So as a
token kindness to existing users of notmuch-folders, I'm at least
making notmuch-hello support the notmuch-folders variable name as an
alternate for the new name of notmuch-saved-searches.
We've recently changed things so that the notmuch-hello screen is the
default view one gets by executing `notmuch'. So hide the "hello" name
from everything exposed in the customize interface, (leaving "hello"
as just an internal name within the implementation).
After the previous commit, toggling the visibility of tags could
result in notmuch-hello aborting with:
Wrong type argument: wholenump, -1
At least, the error only occurred for me when making tags visible. But
that may be because my longest tag name is longer than my longest
saved-search name.
After isearching for an entire saved-search name, the point will be
immediately after that name in the buffer. Before commit
c9ba61bebe the space right after the
name was part of the widget so the user could press RET right after
the isearch to activate the saved search.
The above commit broke that functionality. Restore it by including a
single space after each name as part of the widget.
And off by default. There's a notmuch-hello-show-tags option in
customize to toggle the default setting, as well as buttons to
persistently toggle the visibility for the current session.
I have enough tags in my database that it's quite a bit faster for
notmuch-hello to come up without showing the tags.
Previously, we preserved the current position only when returning to
the notmuch-hello buffer or when refreshing it. Fix to also preserve
the position when directly invoking notmuch-hello, (such as from a
global keybinding).
This give us a useful active widget by default, ("inbox"), and
otherwise gives the first saved search in the user's customized
list. Not having point on the search bar means that the various
keybindings are all available.
This command was previously written under the fragile assumption that
the search bar was always the third widget. That's no longer true with
the saved searches now appearing before the search bar, so we save the
position of the search bar and go directly to it now.
Once users start using saved searches regularly, it's expected that
these will become the primary access points to mail. So give them a
priority position in the buffer.
When we go into a search, and then later quit and return to the
notmuch-hello buffer, we want the point to remain in the same position
it was in when we left. So we have to call the position-remembering
notmuch-hello-update rather than notmuch-hello from the continuation.
Before refreshing, we check which widget we are currently on, (or look
for the next widget), and then we watch for that same widget to go by
when constructing the buffer contents. Finally, we jump to the
position we saw when the widget went by.
Previously, trailing spaces after each saved-search name were included
as part of the widget. This is going to be problematic for a future
change that will extract the widget's value and compare it to the
configured names of saved searches.
Instead, just include the name itself in the widget, and then insert
the spaces for separation afterwards.
The existing code inserts the signature before inserting the message
body (which it puts at the very end of the buffer - therefore AFTER
the signature). This little snippet makes us search backwards and
insert the message body before a signature, if it exists.
This also fixes a small indentation issue in David's code.
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
in the future I'll include those with my patches. Hope it's ok to do
this as one single patch for this series.
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
Previously this was just a message that was almost impossible for the
user to see. Now, the user gets to see the error message, and is
presented with a buffer that actually contains the Fcc header of
interest.
We want to be able to correctly guess the best From: header to use when
replying to emails. This is what we are looking at now:
1 is one of the users' mail addresses in the To: or Cc: header
2 check for an Envelope-to: header
3 check for an X-Original-To: header
4 check for a (for <email@add.res>) clause in Received: headers
5 check for the domain part of known email addresses in the
'by' part of Received headers
6 fall back to the primary email address
This patch changes the algorithm for steps 2-5 of this process. Prior to
this patch we had a first attempt to implement only step 5 - but this
broke in many email setups where mail delivery to the local machine added
additional Received: lines.
Steps 2-4 are new, step 5 now analyzes the concatenated Received: header
(this was in the previous patch) to do this analysis.
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
With this patch the Received: header becomes special in the way
we treat headers - this is the only header for which we concatenate
all the instances we find (instead of just returning the first one).
This will be used in the From guessing code for replies as we need to
be able to walk ALL of the Received: headers in a message to have a
good chance to guess which mailbox this email was delivered to.
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
I have gone wild and added a defcustom "notmuch-fcc-dirs".
Depending on the value of that variable we will not do any
maildir fcc at all (nil, the default), or it is of the format
(("defaultsentbox")
("full name <email@address>" . "Work/sentbox")
("full name2 <email2@address2>" . "Work2/sentbox"))
The outbox name will be concatenated with the message mode
variable "message-directory" which is "~/Mail/" by default.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
1)use insert-buffer-substring
Rather than the insert-buffer. Emacs complains that it is for interactive use
and not for use within elisp. So use insert-buffer-substring which does the
same thing when not handed any 'begin' 'end' parameters.
2)replace caddr with (car (cdr (cdr)))
The former requires 'cl to be loaded and during make install emacs complained
about not knowing it.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Require notmuch-maildir-fcc and also install it.
Rename all jkr/* functions to notmuch-maildir-fcc-*
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
This patch only addresses the typical Outlook/Exchange case
where we have "Last, First" <first.last@company.com> or
"Last, First MI" <first.mi.last@company.com>.
In the future we should be more fexible as to the formats
we recognize, but for now we address this one as it is the
Exchange default setting and therefore the most common one.
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
When displaying threads as result of a search it makes sense to list those
authors first who match the search. The matching authors are separated from the
non-matching ones with a '|' instead of a ','
Imagine the default "+inbox" query. Those mails in the thread that
match the query are actually "new" (whatever that means). And some
people seem to think that it would be much better to see those author
names first. For example, imagine a long and drawn out thread that once
was started by me; you have long read the older part of the thread and
removed the inbox tag. Whenever a new email comes in on this thread,
prior to this patch the author column in the search display will first show
"Dirk Hohndel" - I think it should first show the actual author(s) of the new
mail(s).
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
message->authors contains the author's name (as we want to print it)
get / set methods are declared in notmuch-private.h
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
When completing an address, tell the user how many addresses in the
database matched the query.
Edited-by: Carl Worth <cworth@cworth.org>: Removed a stray numeric
literal that was causing a compiler warning.
Reviewed-by: Carl Worth <cworth@cworth.org>
This variable was moved from notmuch.el to notmuch-lib.el some time
ago, but the declaration in notmuch.el was left around. Clean that up.
Reviewed-by: Carl Worth <cworth@cworth.org>
The notmuch-hello functionality is now sufficiently useful that we
want to make it the default view of notmuch for new users. This also
effectively hides the "hello" name from the user, so we'll be free to
change that in the implementation if necessary.
This change also shuffles the requires between notmuch.el and
notmuch-hello.el. This fixes things so that our documented (require
'notmuch) is sufficient for getting the notmuch-hello functionality.
Finally, the shuffling caused the notmuch-search-oldest-first variable
from one file to the other. While doing that, give this variable the
defcustom treatment for easier customization.
When determining whether or not to re-align the head of the current
message with the top of the window, use `count-screen-lines' rather
than `count-lines' to allow for invisible text in the preceding
message. When comparing that number of lines against
`next-screen-context-lines', realign if the number of lines of the
previous message visible is 'smaller than or equal to' rather than
just 'smaller than' to improve usability.
For composing new messages and forwarding, leave the cursor on the
'To:' field. For replies, leave the cursor at the start of the
body. In all cases, mark the buffer as not modified so that the user
is not prompted if she decides to immediately kill the buffer.
Add:
- notmuch-wash-wrap-long-lines: Wrap lines longer than the width of
the current window whilst maintaining any citation prefix.
- notmuch-wash-tidy-citations: Tidy up citations by:
- compress repeated otherwise blank citation lines,
- remove otherwise blank citation lines at the head and tail of a
citation,
- notmuch-wash-elide-blank-lines: Compress repeated blank lines and
remove leading and trailing blank lines.
None of these is enabled by default - add them to
`notmuch-show-insert-text/plain-hook' to use.
Reviewed-by: Carl Worth <cworth@cworth.org>: I previously committed a
stale version of this patch.
"notmuch-address.el" tries to be careful to insinuate itself into
message mode only if it will do something useful, so it's safe to load
it all of the time.
Set `buffer-invisibility-spec' to `nil' (a list) if it is just `t'
before inserting any body parts, otherwise removing items from
`buffer-invisibility-spec' (which is what
`notmuch-show-headers-visible' and `notmuch-show-message-visible' do)
is a no-op and has no effect. This caused threads with only matching
messages to have those messages hidden initially because
`buffer-invisibility-spec' stayed `t'.
Avoiding adding the same search string to the 'recent searches' list
more than once by testing whether the string was already used with
`member' rather than `memq'.
