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.
We set header-line-format to the message subject, but if the subject
contains percents, the next character is interpreted as a formatting
control, which is not desired.
The TAB-initiated address completion generates completion candidates
synchronously, blocking the UI. Since this can take long time, it is
better to let the use know what's happening.
Make a new customizable variable instead of relying on
message-cite-function because the default for the latter changed
between emacs releases.
The defcustom is borrowed from the message.el source, with minor
modifications.
The faces used when washing messages should be notmuch specific and
inherit from the underlying emacs face rather than using it
directly. This allows the washed face to be modified without requiring
the modification of the underlying face.
`with-current-notmuch-show-message' applies a `no-conversion' coding
system when reading a raw message from notmuch. That coding system
should _not_ be applied when the body of the macro is evaluated, as it
can cause file operations used during that evaluation to incorrectly
apply the `no-conversion' coding system.
This was discovered when a user's .signature file contained non-ASCII
characters. When a message is forwarded, the `no-conversion' coding
system was applied to the reading of the .signature file, resulting in
raw rather than UTF-8 interpretation of the data.
notmuch-jump uses window-body-width which is not defined in emacs
23. To get around this it does
(unless (fboundp 'window-body-width)
;; Compatibility for Emacs pre-24
(defalias 'window-body-width 'window-width))
This makes sure window-body-width is defined and all should be
well. But it seems that the byte compiler does not realise that this
guarantees that window-body-width will be defined and so, when
compiling with emacs 23, it gives an error
In end of data:
notmuch-jump.el:172:1:Warning: the function `window-body-width' is not known to be defined.
Domo and I came to following on irc: wrap the (unless (fboundp ...))
inside eval-and-compile which ensures that both the test and the
defalias (if needed) happen at both compile and load time. This fixes
the warning.
default-value needs its argument to be quoted.
Slightly strangely default-value of 't or nil is 't or nil
respectively so the code
(default-value notmuch-search-oldest-first)
just gives the current value of notmuch-search-oldest-first rather
than intended default-value of this variable.
The symptom is that if you are in a search buffer and use notmuch jump
to run a saved search which does not have an explicitly set sort order
then the sort order of the saved-search is inherited from the current
search buffer rather than being the default search order.
Thanks to Jani for finding the bug.
Fix byte compiler warning "Warning: the function `window-body-width'
is not known to be defined." by moving our compatibility wrapper
before its use and simplify the definition to a defalias for the old
name of the function.
