When notmuch sources are at a symlinked path, some tests fail because
one part of the test uses physical path and another uses logical
path (with symlinks). For example the following test output is
produced when the test is started from /home/src/symlink-to-notmuch,
which is a symlink to /home/src/notmuch.
FAIL notmuch-fcc-dirs set to a string
--- T310-emacs.26.OUTPUT 2015-12-29 08:54:29.055878637 +0000
+++ T310-emacs.26.EXPECTED 2015-12-29 08:54:29.055878637 +0000
@@ -1,5 +1,5 @@
From: Notmuch Test Suite <test_suite@notmuchmail.org>
To:
Subject:
-Fcc: /home/src/notmuch/test/tmp.T310-emacs/mail/sent-string
+Fcc: /home/src/symlink-to-notmuch/test/tmp.T310-emacs/mail/sent-string
--text follows this line--
nil
This commit makes all paths in test scripts physical. With it, all
tests pass even when run from a symlinked directory.
This gives some additional access to debugging information when using
the python bindings.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
This does not play well with --prefix. As Tomi notes in
id:m2k2p2rwth.fsf@guru.guru-group.fi, people still have the option of e.g.
% ./configure ---emacslispdir=`pkg-config emacs --variable sitepkglispdir`
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.
We can't (but currently do) allow upgrades within transactions because
upgrades need their own transactions. We don't want to re-use the
current transaction because bailing out of an upgrade would mean loosing
all previous changes (because our "atomic" transactions don't commit
before hand). This gives us two options:
1. Fail at the beginning of upgrade (tell the user to end the
transaction, upgrade, and start over).
2. Don't allow the user to start the transaction.
I went with the latter because:
1. There is no reason to call `begin_atomic` unless you intend to to
write to the database and anyone intending to write to the database
should upgrade it first.
2. This means that nothing inside an atomic transaction can ever fail
with NOTMUCH_STATUS_UPGRADE_REQUIRED.
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.
These tests are inspired by a problem report
id:CAJhTkNh7_hXDLsAGyD7nwkXV4ca6ymkLtFG945USvfqK4ZJEdQ@mail.gmail.com
Of course I can't duplicate the mentioned problem, it probably depends
on specific message data.
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.
This patch removes the restriction on notmuch-tag that disallows using
both --remove-all and --batch. Combining the two options removes tags
on all messages affected by each query before applying the new tags.
Per RFC 2183, the values for Content-Disposition values are not
case-sensitive. While at it, use the gmime function for getting at the
disposition string instead of referencing the field directly.
This fixes attachment display and quoting in notmuch show and reply,
respectively.
Per RFC 2183, the values for Content-Disposition values are not
case-sensitive. While at it, use the gmime function for getting at the
disposition string instead of referencing the field directly.
This fixes "attachment" tagging and filename term generation for
attachments while indexing.
... in addition to doing this when these variables are unset.
It is more useful to use defaults (emacs or emacsclient) than empty
string as a command name.
Check that copyright year will be current year in generated documentation.
Checking is done my matching that copyright line contains current year
as a substring which is good enough "approximation" in this context.
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.
this is a minor security hole, but no worse than what we had before. In
particular the worst that happens is someone prevents us from making a
release. Which is hardly worth the trouble of jacking the URL.
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 adds NEWS items for
the new limit/filter function in notmuch-show,
the saved-search option for tree view,
the binding S to run the current tree-view search in notmuch-search,
the increase in max text part size
the bugfix for replying to encrypted messages from tree view
Add support for completing --help, --uuid=, and --version after the
subcommand. Do not support shared options at the top level yet due to
difficulties in handling options with arguments.
--uuid necessitates adding 'compopt -o nospace' also to notmuch new
completion, but that just brings it in line with the rest.
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.
<since> and <until> for the lastmod: prefix right below the date:
prefix description give the impression one could use last modified
dates to lastmod: which is not at all the case. Use
<initial-revision>..<final-revision> instead.
Trailing dots were removed from 3 NEWS items so that those appear in
same level as surrounding "heading" lines in generated wiki page.
One trailing dot was added to nmbug-status item so it appears as normal
text in generated wiki page. `nmbug-status` was put in backticks so it
looks the same as in older nmbug-status news text.
