This ensures that the temporary copy of the current message-mode
buffer is whole and not limited by a current restriction.
An example of such restriction is the default one established by
message-mode when composing a reply, that hides the References,
In-Reply-To and similar headers.
This fixes the bug reported by dkg in [1]. The movement of the call to
n-m-setup-message-for-saving is so the cleanup of Fcc headers happens
in the encoded version (otherwise Fcc headers may be saved to disk).
[1]: id:87k1zm225v.fsf@fifthhorseman.net
With [1: 16b2db09] we lost the (undocumented) option to use no Fcc
header only for From addresses matching a regexp. This brings back
that feature and documents it.
1: 2021-01-15 16b2db0986
emacs: various cosmetic improvements
Although the function dates from 2015, the autoload is newer. In
particular [1] it is not found in Emacs 25.3.
[1]: id:874ke85tqx.fsf@cgc-instruments.com
We need to load `cl-lib' at run-time because we use more from it than
just macros. Never-the-less many, but not all libraries required it
only at compile-time, which we got away with because at least some
libraries already required it at run-time as well.
We use `cl-lib' and (currently to a lesser extend) `pcase' throughout
the code-base, which means that we should require these features in
most libraries.
In the past we tried to only require these features in just the
libraries that actually need them, without fully succeeding. We did
not succeed in doing so because that means we would have to check
every time that we use a function from these features whether they
are already being required in the current library.
An alternative would be to add the `require' forms at the top of every
library but that is a bit annoying too.
In order to make sure that these features are loaded when needed but
also to keep the noise down we only require them in "notmuch-lib.el",
which most other libraries require, and in most of the few libraries
that do not do so, namely "notmuch-draft.el", "notmuch-message.el" and
"notmuch-parser.el". ("coolj.el", "make-deps.el", various generated
libraries, and "notmuch-compat.el" are left touched.)
To some extend this is a personal preference, but the preference is
strongly dependent on whether one is used to a language that makes it
necessary to use variables like this.
This makes it perfectly clear that we are first getting and then using
a "foo":
(use-foo (get-foo))
Sure this has to be read "inside out", but that's something one better
gets used to quickly when dealing with lisp. I don't understand why
one would want to write this instead:
(let ((the-foo (get-foo)))
(use-foo the-foo))
Both `get-foo' and `use-foo' are named in a way that make it very
clear that we are dealing with a "foo". Storing the value in an
additional variable `the-foo' does not make this any more clear.
On the contrary I makes the reader wonder why the author choose to
use a variable. Is the value used more than once? Is the value
being retrieved in one context and then used in another (e.g. when
the current buffer changes)?
The previous commit switched to lexical-binding but without dealing
with the new warnings about unused lexical arguments and variables.
This commit deals with most of them, in most cases by either removing
leftover bindings that are actually unnecessary, or by marking certain
arguments as "known to be unused" by prefixing their names with "_".
In the case of the functions named `notmuch-show-insert-...' the
amount of silencing that is required is a bit extreme and we might
want to investigate if there is a better way.
In the case of `notmuch-mua-mail', ignoring CONTINUE means that we do
not fully follow the intended behavior described in `compose-mail's
doc-string.
Doing so causes many new compile warnings. Some of these warnings
concern genuine changes in behavior that have to be addressed right
away.
Many other warnings are due to unused variables. Nothing has changed
here, except that the byte-compiler can now detect these pre-existing
and harmless issues. We delay addressing these issues so that we can
focus on the important ones here.
A third group of warnings concern arguments that are not actually used
inside the function but which cannot be removed because the functions
signature is dictated by some outside convention. Silencing these
warning is also delayed until subsequent commits.
`outline-minor-mode' treats comments that begin with three or more
semicolons as headings. That makes it very convenient to navigate
code and to show/hide parts of a file.
Elips libraries typically have four top-level sections, e.g.:
;;; notmuch.el --- run notmuch within emacs...
;;; Commentary:...
;;; Code:...
;;; notmuch.el ends here
In this package many libraries lack a "Commentary:" section, which is
not optimal but okay for most libraries, except major entry points.
Depending on how one chooses to look at it, the "... ends here" line
is not really a heading that begins a section, because it should never
have a "section" body (after all it marks eof).
If the file is rather short, then I left "Code:" as the only section
that contains code. Otherwise I split the file into multiple sibling
sections. The "Code:" section continues to contain `require' and
`declare-function' forms and other such "front matter".
If and only if I have split the code into multiple sections anyway,
then I also added an additional section named just "_" before the
`provide' form and shortly before the "...end here" line. This
section could also be called "Back matter", but I feel it would be
distracting to be that explicit about it. (The IMO unnecessary but
unfortunately still obligatory "... ends here" line is already
distracting enough as far as I am concerned.)
Before this commit some libraries already uses section headings, some
of them consistently. When a library already had some headings, then
this commit often sticks to that style, even at the cost inconsistent
styling across all libraries.
A very limited number of variable and function definitions have to be
moved around because they would otherwise end up in sections they do
not belong into.
Sections, including but not limited to their heading, can and should
be further improved in the future.
Most people who write lots of lisp tend to only sparsely use empty
"separator" lines within forms. In lisp they feel unnecessary and
since most files stick to this convention we get a bit confused
when there are extra empty lines. It feels like the s-expressions
are falling into pieces.
All of this is especially true between a function's doc-string and
body because the doc-string is colored differently, which visually
already separates it quite sufficiently from the code that follows.
Fixed emacs docstrings to be consistent. No functional change.
- removed some (accidental) indentation
- removed some trailing newlines
- added trailing periods where missing (some exclusions)
Starting with Emacs 27 the old `cl' implementation is finally
considered obsolete. Previously its use was strongly discouraged
at run-time but one was still allowed to use it at compile-time.
For the most part the transition is very simple and boils down to
adding the "cl-" prefix to some symbols. A few replacements do not
follow that simple pattern; e.g. `first' is replaced with `car',
even though the alias `cl-first' exists, because the latter is not
idiomatic emacs-lisp.
In a few cases we start using `pcase-let' or `pcase-lambda' instead
of renaming e.g. `first' to `car'. That way we can remind the reader
of the meaning of the various parts of the data that is being
deconstructed.
An obsolete `lexical-let' and a `lexical-let*' are replaced with their
regular variants `let' and `let*' even though we do not at the same
time enable `lexical-binding' for that file. That is the right thing
to do because it does not actually make a difference in those cases
whether lexical bindings are used or not, and because this should be
enabled in a separate commit.
We need to explicitly depend on the `cl-lib' package because Emacs
24.1 and 24.2 lack that library. When using these releases we end
up using the backport from GNU Elpa.
We need to explicitly require the `pcase' library because
`pcase-dolist' was not autoloaded until Emacs 25.1.
Apparently, message-default-charset is deprecated, which causes the
following warning messages during the build:
In notmuch-maildir-setup-message-for-saving:
emacs/notmuch-maildir-fcc.el:172:31:Warning: ‘message-default-charset’ is an
obsolete variable (as of 26.1); The default charset comes from the
language environment
In discussion with emacs upstream over on
https://debbugs.gnu.org/35370, it appears that we can just drop this
entirely and things should still work with emacs 25.
Fix the deprecation warning:
In notmuch-maildir-fcc-make-uniq-maildir-id:
emacs/notmuch-maildir-fcc.el:279:53:Warning: ‘system-name’ is an obsolete
variable (as of 25.1); use (system-name) instead
I've used (system-name) since at least 2011, so it must have been
around quite a while.
Some of the recent changes to the emacs code have used functions
introduced in emacs 24. The functions used are read-char-choice and
setq-local. This changeset adds a file notmuch-compat.el which
contains compatibility functions so that it should work on emacs
23.
Note, since these functions are taken almost unchanged from the emacs
source they are copyright the Free Software Foundation, and the header
in the file reflects that.
This commit expands docstrings for notmuch-fcc-dirs and
notmuch-maildir-fcc-with-notmuch-insert to describe how quoted strings
are processed and make the ability to configure sent folders containing
whitespace more discoverable.
With all the preparation it is now simple to add the actual insert
code. Since insert can fail for many reasons we let the user decide
interactively deal with it.
We modify test-lib.el to set file fcc, so that all the old tests and
emacs_fcc_message from test-lib.sh still work
We will need our own local copy of message-do-fcc so this commit just
copies the code straight from message.el so that it is easier to see
our local changes coming in the next commit.
We move some code around in preparation for the use of notmuch
insert. In particular, we move the check for a valid maildir for the
fcc to when the message is sent rather than when the fcc header is
inserted. The main motivation is consistency with the insert version
(coming later) where we cannot check the validity until send.
We allow the user some chance to correct the header; the choice here
is intended to be consistent with the insert version to come.
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.
Previously, the timestamp at the beginning of the FCC unique maildir
name was derived incorrectly, thanks to an integer overflow. This
changes the derivation of timestamp to use a float, and so will get
the number correct at least until 2038. (It is still formatted with
"%d" so it will show up as an integer.) Should we need to change it in
the next 26 years to take the unix millenium into account, it will be
invisible to users.
This change is mostly a question of consistency, since the unique name
is arbitrary anyway. But since most people use timestamps, and that was
the original intention here as well, we might as well.
Signed-off-by: Jesse Rosenthal <jrosenthal@jhu.edu>
To allow for expansion whilst keeping everything tidy and organized,
move all defcustom/defface variables to the following subgroups,
defined in notmuch-lib.el:
- Hello
- Search
- Show
- Send
- Crypto
- Hooks
- External Commands
- Appearance
As an added benefit, defcustom keyword args are now consistently
ordered as they appear @ defcustom's docstring (OCD much?).
Proper defgroup docstrings and various other improvements
by courtesy of Austin Clements.
Various typo fixes in error messages within the source code.
Signed-off-by: Pieter Praet <pieter@praet.org>
Edited-by: Carl Worth <cworth@cworth.org> Restricted to just error messages.
This error occurs when `notmuch-fcc-dirs' is set to a list. The error
was in the `notmuch-fcc-dirs' format check which was changed in an
incompatible way from 0.4 to 0.5.
The fix was extracted from a bigger patch series by David
Edmondson id:"1290682750-30283-2-git-send-email-dme@dme.org".
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
For message-fetch-field the buffer is expected to be narrowed to
just the header of the message. That is not the case when
notmuch-fcc-header-setup is run, hence a wrong header value may be
returned. E.g. when forwarding an
email, (message-fetch-field "From") returns the From header value
of the forwarded email.
Message-field-value is the same as message-fetch-field, only
narrows the buffer to the headers first.
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
Appease the test suite by using the true name for the Fcc directory
path, otherwise a value for `notmuch-database-path' which includes
symbolic links causes test suite failures.
Re-work the declaration and definition of `notmuch-fcc-dirs'. The
variable now allows three types of values:
- nil: no Fcc header is added,
- a string: the value of `notmuch-fcc-dirs' is the name of the
folder to use,
- a list: the folder is chosen based on the From address of the
current message using a list of regular expressions and
corresponding folders:
((\"Sebastian@SSpaeth.de\" . \"privat\")
(\"spaetz@sspaeth.de\" . \"OUTBOX.OSS\")
(\".*\" . \"defaultinbox\"))
If none of the regular expressions match the From address, no
Fcc header will be added.
Call notmuch-fcc-header-setup from message-header-setup-hook rather
than message-send-hook. This allows you to see what's going to
happen, and to make manual adjustments if desired. Gnus does
something similar.
Signed-off-by: Rob Browning <rlb@defaultvalue.org>
Now that the FCC code is fixed to use the notmuch database path, we can
actually enable this by default, which should be highly useful for all
new users of notmuch.
Otherwise, FCC is too hard to use, (user must set it and also set message-
directory variable to match notmuch mail datbase path). As a rule, I'd like
for users of notmuch to not be required to muck around with non-notmuch
mail settings in emacs.
The above is only really possible now thanks to the recent addition of the
"notmuch config get" command which allows emacs to query the currently
configured notmuch database path.
This also now allows an absolute-path FCC to be set if desired.
In the common case that a user only has one FCC (save outgoing mail in
the Mail directory, it is now possible to simply configure a string
such as "Sent" in the notmuch-fcc-dirs variable. More complex options,
depending on a users email address, are possible and described in the
variable customization help text.
The whole function notmuch-fcc-header-setup has been cleaned up a
little while working on that.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
The fcc code would only initialize if notmuch-fcc-dirs was set. This was
a problem if you reset the variable, or added the variable later during
initialization. Now we always add the fcc hook, but it doesn't do
anything unless notmuch-fcc-dirs are set.
