Previously if a marking read tag change (i.e., removing the unread
tag) failed for some reason, such as a locked database, then no more
mark read tag changes would be attempted in that buffer.
This handles the error more gracefully. There is not much we can do
yet about dealing with the error itself, and marking read is probably
not important enough to warrant keeping a queue of pending changes or
anything.
However this commit changes it so that
- we do try and make future mark read tag changes.
- we display the tag state correctly: i.e. we don't display the tag as
deleted (no strike through)
- and since we know the tag change failed we can try to mark this
message read in the future. Indeed, since the code uses the
post-command hook we will try again on the next keypress (unless the
user has left the message).
We indicate to the user that these mark read tag changes may have
failed in the header-line.
Many of the external links found in the notmuch source can be resolved
using https instead of http. This changeset addresses as many as i
could find, without touching the e-mail corpus or expected outputs
found in tests.
This binding is similar to mutt's, which is
bind {mode} b "bounce-message" # remail a message to another user
where {mode} is 'index', 'pager' or 'attach'.
The new function notmuch-show-message-resend re-sends
message to new recipients using #'message-resend.
Recipients are read from minibuffer as a comma-separated
string (with some keyboard support including tab completion).
Final confirmation before sending is asked.
When composing messages (including replies, etc.), indicate to
`message-mode' definitively that the message is email (as opposed to
Usenet news) rather than having it attempt to determine this for itself.
This causes `message-mode' to observe such variables as
`message-default-mail-headers', which previously happened haphazardly.
`notmuch--get-bodypart-raw' previously assumed that all non-binary MIME
parts could be successfully read by assuming that they were UTF-8
encoded. This was demonstrated to be wrong, specifically when a part was
marked as ISO8859-1 and included accented characters (which were
incorrectly rendered as a result).
Rather than assuming UTF-8, attempt to use the part's declared charset
when reading it, falling back to US-ASCII if the declared charset is
unknown, unsupported or invalid.
Please put my address in CC when replying. Thanks!
From 4b9ab261a0ea8a31065e310c5150f522be86d37b Mon Sep 17 00:00:00 2001
From: stefan <aeuii@posteo.de>
Date: Fri, 8 Apr 2016 22:47:06 +0200
Subject: [PATCH] emacs: make use of `message-make-from'
Will respect `mail-from-style'.
When no decryption or signature examination is
happening (i.e. `notmuch-crypto-process-mime' is `nil') insert buttons
that indicate this, rather than remaining silent.
Currently the preference for which sub-part of a multipart/alternative
part is shown is global. Allow to the user to override the settings on a
per-message basis by providing the ability to call a function that has
access to the message to return the discouraged type list.
The original approach is retained as the default.
`notmuch-get-bodypart-text' assumed that it is always possible to
acquire text/* parts via the sexp output format. This is not true if the
part in question has a content type of application/octet-stream but is
being interpreted as text/* based on the extension of the part filename.
Rework `notmuch-get-bodypart-text' to use the raw output format to
address this and make the implementation common with that of
`notmuch-get-bodypart-binary'.
Move the brief help text at the bottom of the hello screen to the
notmuch-hello-mode help, and promote '?' as the universal help key
across Notmuch. This unclutters the hello screen, and allows for a
more verbose description in the mode help. Hopefully, this change is
useful for both experienced and new users alike.
While at it, improve the links to Notmuch and hello screen
customization.
Add a customizable function specifying which parts get a header when
replying, and give some sensible possiblities. These are,
1) all parts except multipart/*. (Subparts of a multipart part do
receive a header button.)
2) only included text/* parts.
3) Exactly as in the show buffer.
4) None at all. This means the reply contains a mish-mash of all the
original message's parts.
In the test suite we set the choice to option 4 to match the
previous behaviour.
Use the message display code to generate message text to cite in
replies.
For now we set insert-headers-p function to
notmuch-show-reply-insert-header-p-never so that, as before, we don't
insert part buttons.
With that choice of insert-headers-p function there is only one
failing test: this test has a text part (an email message) listed as
application/octet-stream. Notmuch show displays this part, but the
reply code omitted it as it had type application/octet-stream. The new
code correctly includes it. Thus update the expected output to match.
This allows callers of notmuch-show-insert-bodypart to use a `let'
binding to override the default function for specifying when part
headers should be inserted.
We also add an option to never show part buttons which will be used by
the test suites for the reply tests.
If the basic query passed to `notmuch-show' generates no results, ring
the bell and inform the user that no messages matched the query rather
than displaying an empty buffer and showing an obscure error.
Similarly when refreshing a `notmuch-show' buffer and no messages match.
Change the key binding for filter (or "limit") in search-mode. This
gives consistency with the new filter in show-mode, and frees 'f' for
forward-thread in the future.
As pointed out by David Bremner, Elisp manual says "A common pitfall
is to use a quoted constant list as a non-last argument to ‘nconc’."
Since this was the case in recently added code, we fix it here.
notmuch-mua-mail ignored the switch-function argument and always used
the function returned by notmuch-mua-get-switch-function instead. In
order to support standard emacs interfaces (compose-mail in this
case), this commit changes notmuch-mua-mail to use the switch-function
argument if it is non-nil and notmuch-mua-get-switch-function
otherwise.
Commit 570c0aeb40 reworked
notmuch-mua-mail function in a way that worked only under Emacs 24.
The reason was that message-setup-1 took one argument less in Emacs
23.
We fix this by only supplying the return-action argument when it is
actually set by the caller.
Recent addition of notmuch-message-mode introduced several problems:
1. When message-setup-hook is used to set buffer local variables,
these settings are not effective, because all buffer local
variables are immediately erased by notmuch-message-mode
initialization.
2. message-mode-hook gets invoked twice - first when message-mail
invokes message-mode and second when notmuch-mua-mail invokes
notmuch-message-mode.
This commit fixes these problems by replacing a call to message-mail
with notmuch-specific code that is (hopefully) equivalent to
message-mail functionality before introduction of
notmuch-message-mode.
We first initialize notmuch-message-mode with
notmuch-mua-pop-to-buffer, which is a modified version of
message-pop-to-buffer and then call message-setup-1, which is the only
functionality of message-mail that is needed for notmuch.
Previously poll called from emacs would fail silently. This makes it
return a useful error message.
In the non-deprecated case of notmuch new and appropriate hooks, it
uses notmuch-call-notmuch-process which gives an error and
additionally puts the stdout/stderr etc in the *Notmuch errors*
buffer.
In the deprecated case of a custom poll script it only returns an
error message.
Commit based on a bug report, and a potential fix, by Ketil Malde.
In emacs24 we use make-composed-keymap. It seems that if only a single
map is specified then emacs just resuses it rather than creating a
copy of it. Thus use make-sparse-keymap to force a copy.
emacs/make-depend.el will compute all other related dependencies
except this one:
notmuch-version is not top-level `require' expression in
notmuc-lib.el[c] but conditional based on the existence of
notmuch-version.el[c].
emacs/make-depend.el does not know now notmuch-version.el[c] becomes
into existence but emacs/Makefile.local does know.
notmuch-show-view-raw-message() re-uses buffer created with same
name (same Message-Id:) but it did not erase it before filling.
If this ever happened, there were duplicated (potentially overlapping)
content in the buffer. Now this is fixed.
Apparently since emacs 24.5 the (view-buffer) makes the buffer read-only;
so this problem would not have happened there, just that
notmuch-show-view-raw-message() failed. This is fixed by setting
inhibit-read-only t before erasing and filling the buffer. The emacs 24.5
feature having raw message buffer read-only is also now explicitly set to
the buffer so the same experience is available with emaces < 24.5.
Flyspell mode uses a special setting for message-mode to not
spell-check message headers except Subject. Apply this setting also to
notmuch-message-mode.
Commit e26d767897 changed the
fontification of the body associated with the From header to
message-header-from. However, that face is non-existent, and in
message.el (message-font-lock-keywords) the From-header falls through
and is attributed the message-header-other face.
This commit removes the fontification of the [Ff]rom header in
notmuch-show-mode in order to fontify it using the message-header-other
face.
This only affects non-default configurations where
notmuch-message-headers is set to display From.
When company-mode is available (Emacs >= 24), address completion
candidates are shown in a nice popup box. This is triggered either by
pressing TAB or by waiting a while during typing an address. The
completion is based entirely on the asynchronous address harvesting
from notmuch-address.el so the GUI is theoretically not blocked for
long time.
The completion works similarly as the TAB-initiated completion from
notmuch-address.el, i.e. quick harvest based on user input is executed
first and only after full harvesting is finished, in-memory cached data
is used.
[Improved by David Bremner]
Currently, notmuch has an address completion mechanism that requires
external command to provide completion candidates. This commit adds a
completion mechanism inspired by https://github.com/tjim/nevermore,
which is implemented in Emacs lisp only.
The preexisting address completion mechanism, activated by pressing
TAB on To/Cc lines, is extended to use the new mechanism when
notmuch-address-command to 'internal, which is the new default.
The core of the new mechanism is the function notmuch-address-harvest,
which collects the completion candidates from the notmuch database and
stores them in notmuch-address-completions variable. The address
harvesting can run either synchronously (same as with the previous
mechanism) or asynchronously. When the user presses TAB for the first
time, synchronous harvesting limited to user entered text is performed.
If the entered text is reasonably long, this operation is relatively
fast. Then, asynchronous harvesting over the full database is triggered.
This operation may take long time (minutes on rotating disk). After it
finishes, no harvesting is normally performed again and subsequent
completion requests use the harvested data cached in memory. Completion
cache is updated after 24 hours.
Note that this commit restores (different) completion functionality for
users when the user used external command named "notmuch-addresses",
i.e. the old default. The result will be that the user will use
the new mechanism instead of this command. I believe that many users may
not even recognize this because the new mechanism works the same as
http://commonmeasure.org/~jkr/git/notmuch_addresses.git and perhaps also
as other commands suggested at
http://notmuchmail.org/emacstips/#address_completion.
[This feature was significantly improved by David Bremner and Mark Walters]
This allows e.g. Gnus users to load this file without changing
message-mode behaviour.
This will disable completion for those that did not customize the
variable but relied on the existence of a file named "notmuch-addresses"
in their path. In the next commit the default behaviour will change to
use a "workalike" internal completion mechanism.
This patch allows the user to customize a saved search to choose tree
view rather than the default search view. It also updates notmuch-jump
so that it respects this choice.
Currently notmuch-show-max-text-part-size is 10000 which means some
relatively normal messages have all parts hidden by default. Increase
this to 100000 by default.
The setting was introduced to alleviate problems with notmuch being
very slow on large threads. Users hitting these problems may wish to
customize this variable to something smaller (like 10000).
Formerly replying to an encrypted message in tree-view did not work:
the message was not decrypted. This commit makes notmuch-tree respect
the setting of notmuch-crypto-process-mime. In particular, if
notmuch-crypto-process-mime is set to t, then replying to encrypted
messages in tree mode will now decrypt the reply (as it already did in
show mode).
When filtering the current search further with notmuch-search-filter,
wrap the current search in parens (if necessary).
This fixes unexpected behavior when the current search is
complex (like "(tag:this and date:one_week_ago..) or tag:that").
