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").
Previously we globally modified these variables, which tended to cause
problems for people using message-mode, but not notmuch-mua-mail, to
send mail.
User visible changes:
- Calling notmuch-fcc-header-setup is no longer optional. OTOH, it
seems to do the right thing if notmuch-fcc-dirs is set to nil.
- The Fcc header is visible during message composition
- The name in the mode line is changed, and no longer matches exactly
the menu label.
- Previously notmuch-mua-send-and-exit was never called. Either we
misunderstood define-mail-user-agent, or it had a bug. So there was
no difference if the user called message-send-and-exit directly. Now
there will be.
- User bindings to C-c C-c and C-c C-s in message-mode-map are
overridden. The user can override them in notmuch-message-mode-map,
but then they're on their own for Fcc handling.
This is to provide a clean way of overriding e.g. keybindings when
sending mail from notmuch.
This is needed in particular to allow somewhere to dynamically bind
certain message-mode variables which are not respected when buffer-local. See e.g.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21174
Now that we have `notmuch-emacs-version' defined in notmuch emacs MUA
use that as a part of User-Agent: header to provide more accurate
version information when sending emails.
In case some incomplete installation of notmuch emacs MUA is used and
`notmuch-emacs-version' is defined as "unknown" then fall back to ask
version info from cli (as it used to be before this commit).
Requiring notmuch-version[.elc] and if that is missing setting
"fallback" notmuch-emacs-version (to "unknown") was moved from
notmuch.el to notmuch-lib.el as notmuch-mua.el (which provides
User-Agent: information) require's the latter.
Show the current thread with a different filter (i.e., open messages
in the thread matching the new query).
Bound to 'l' for "limit".
Note that it is not the same as filter in search mode as it replaces
the existing query rather than ANDing with it (but it does keep the
thread-id part of the query).
Separate out a notmuch-show-goto-msg-id sub-function from
notmuch-show-apply-state. There should be no functional change but the
next patch will call the new function.
The second argument to notmuch-tag is now called tag-changes, but the
documentation for notmuch-before-tag-hook and notmuch-after-tag-hook
still used the old argument name `tags'. This resulted in broken hooks
when following the documentation.
The mark read code for tree mode did not get updated in the recent
changes. This updates it to match. Since the user can customize the
mark read logic we just call the show logic in the message pane.
The notmuch-search-terms man page states that "tag:<tag>" is equivalent
to "is:<tag>". Completion for "is:<tag>" style searches is now supported
in the Emacs interface.
Amended by David Bremner: combine lexical-let and let into
lexical-let*
notmuch-show can be slow displaying large attachments so hide them by
default. The default maximum size is 10000 bytes/characters but it is
customizable.
Note that notmuch-show-insert-bodypart is also called from the reply
code so we need to be a little careful.
Besides generally cleaning up the code and separating the general
content ID handling from the w3m-specific code, this fixes several
problems.
Foremost is that, previously, the code roughly assumed that referenced
parts would be in the same multipart/related as the reference.
According to RFC 2392, nothing could be further from the truth:
content IDs are supposed to be globally unique and globally
addressable. This is nonsense, but this patch at least fixes things
so content IDs can be anywhere in the same message.
As a side-effect of the above, this handles multipart/alternate
content-IDs more in line with RFC 2046 section 5.1.2 (not that I've
ever seen this in the wild). This also properly URL-decodes cid:
URLs, as per RFC 2392 (the previous code did not), and applies crypto
settings from the show buffer (the previous code used the global
crypto settings).
Unibyte strings are meant for representing binary data. In practice,
using unibyte versus multibyte strings affects *almost* nothing. It
does happen to matter if we use the binary data in an image descriptor
(which is, helpfully, not documented anywhere and getting it wrong
results in opaque errors like "Not a PNG image: <giant binary spew
that is, in fact, a PNG image>").
`notmuch-get-bodypart-content' could do two very different things,
depending on conditions: for text/* parts other than text/html, it
would return the part content as a multibyte Lisp string *after*
charset conversion, while for other parts (including text/html), it
would return binary part content without charset conversion.
This commit completes the split of `notmuch-get-bodypart-content' into
two different and explicit APIs: `notmuch-get-bodypart-binary' and
`notmuch-get-bodypart-text'. It updates all callers to use one or the
other depending on what's appropriate.
The new function, `notmuch-get-bodypart-binary', replaces
`notmuch-get-bodypart-internal'. Whereas the old function was really
meant for internal use in `notmuch-get-bodypart-content', it was used
in a few other places. Since the difference between
`notmuch-get-bodypart-content' and `notmuch-get-bodypart-internal' was
unclear, these other uses were always confusing and potentially
inconsistent. The new call clearly requests the part as undecoded
binary.
This is step 1 of 2 in separating `notmuch-get-bodypart-content' into
two APIs for retrieving either undecoded binary or decoded text.
