We shouldn't force `ido-completion-read' on users who do not otherwise
use Ido. Unfortunately simply turning on `ido-mode' does not change
every `completing-read' into a `ido-completing-read', instead it only
changes file and buffer completion.
I do realize that existing Ido users will initially dislike this
change, but I would like to encourage them to see this as an
opportunity to learn about Fido.
Unlike `ido-mode', build-in `fido-mode' confirms to the standard
completion API, so turning it on causes every `completing-read' to
use the Fido completion mechanism and which is similar to the Ido
mechanism:
> An enhanced `icomplete-mode' that emulates `ido-mode'. This global
> minor mode makes minibuffer completion behave more like `ido-mode'
> than regular `icomplete-mode'."
`notmuch-show-insert-part-text/plain' calls
`notmuch-show-insert-text/plain-hook' with two arguments
MSG and DEPTH. Currently all hook functions ignore MSG but
third-party functions may not. One hook function uses DEPTH.
This function had a few issues.
- Neither its name nor the old comment before it is called made it
clear what it does.
- It took one argument but didn't do anything with it.
- It's doc-string made a few claims, which are untrue and generally
focused on details instead of that its purpose is.
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.
In practice this probably does not make a difference or we would
have heard about it many times, but better be safe than sorry.
Process sentinels are called not only when the process has finished
but also on other state changes.
When running "notmuch" we use its full path but when displaying the
command to the user we show just its name for readability reasons.
Avoid passing around both representations because it is very easy
to get the name from the path.
Notmuch itself uses the involved functions just for "notmuch" but
there might be extensions that use them for other executable so we
forgo other potential simplifications.
The buffer of the error process is accessible using `process-buffer'.
We still have to store the error-buffer in the non-error process
because for that process `process-buffer' obviously returns its own
buffer.
We no longer support Emacs releases before version 25.1.
Also adjust the sentinels which only had to deal with
an error file when using an older Emacs release was used.
These functions are used as action/notify functions. That dictates
the appropriate function signatures but even though these functions
are not used for anything else they use incompatible signatures,
forcing the callers to use lambda expressions to deal with these
incompatibilities.
Fix that by adjusting the function signatures to the needs of the
only intended callers.
Two of these functions were defined as commands but because the
interactive form did not return the mandatory arguments, we know
that nobody (successfully) used these as commands.
In one case we move the location of a y-or-n-p prompt.
Whenever setting background color, set also corresponding
foreground color. Don't expect default foreground color to
be #000 (or something close); user may have changed it.
This reverts commit f9fbd1ee3b.
Emacs provides a mechanism for avoiding wiping out buffer-local
variables: marking them as "permanent local", which essentially
means "don't wip out the local value when enabling major-mode".
(put 'the-variable 'permanent-local t)
See (info "(elisp)Creating Buffer-Local").
Whether refreshing the buffer contents should involve re-enable the
mode is a different question, which should not be decided based on
the fact that we want keep the value of some random variable, not
least because some other (e.g. cache) variables are likely expected
to be wiped.
These were originally committed by git-debrebase. Unfortunately git
debrebase does not seem to like the notmuch git workflow, so giving up
on it for now.
readelf on (at least) ppc64le sometimes generates some extension to
the Ndx name inside '[]'. Remove this output to allow our simple
column based parsing to work.
A typo in Database._create_query lost the exclude_tag names during the
string to utf-8 conversion.
Amended by DB: fixed patch format and updated commit message.
database.cc is uncomfortably large, and some of the static data
structures do not need to be shared as much as they are.
This is a somewhat small piece to factor out, but it will turn out to
be helpful to further refactoring.
It turns out that using nm -P isn't as portable as hoped. In
particular with some ELF ABIs (e.g. ppc64 ELFv1), the desired symbols
end up in the data section instead of text.
The test is currently only functional on ELF based architectures, so I
think it's legit to depend on readelf instead of nm.
The switch to readelf has the advantage that we can explicitely ask
for all of the symbols with global visibility, rather than grepping
for notmuch. That seems a more robust approach since it will catch any
strangely named global symbols.
Under a sufficiently high level of parallelism [1] there seems to be a
a race condition that allows sphinx-build to start running before the
docstrings are extracted. This change moves the docstring stamp from
the phony targets sphinx-html and sphinx-info to the file targets that
they depend on. I'm not sure why this makes things better, but I am
fairly confident it does not make things worse, and experimentally it
seems to eliminate the race condition.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976934
