When show mode is invoked it could be displaying just the matched messages
or everything. This flag is passed to NM_search_show_thread(). It is then
stored in a buffer variable, b:nm_show_everything, and used for subsequent
calls to NM_search_show_thread() triggered by <Space>, <C-n> and <C-p>.
Signed-off-by: Bart Trojanowski <bart@jukie.net>
This is the long-awaited feature that when viewing a thread resulting
from a search, only the messages that actually match the search will
be opened initially (in addition to unread messages).
So now, it's finally useful to tag a single message in a giant thread,
and then do a search later and easily find just the single tagged
message.
There's no visible change here---we're just making the button extend
through the invisible portions of the message before the
message-summary line. The reason this is important is that it's easy
for the user to position point at the (invisible) `point-min', so we
want to ensure that there's a valid button there.
The defun special form doesn't require a progn. And the remainder
of the function was previously indented in a misleading way, (as
if each "if" was always evaluated, rather than each only being
evaluated if all the previous evaluated to nil).
This function was still implemented in terms of the old, global toggle
for visibility of unread messages, (which no longer exists). Fix it to
use the local 'invisibility-spec property on the button controlling
message visibility.
A new item from IRC discussion, (speeding up "notmuch restore"), as
well as a bug I just hit myself, (content from citations is not being
indexed).
While here, notce that several items have recently been completed ('?'
now displays documentation, not function names; we have a search
binding from notmush-show-mode; and "notmuch new" responds to SIGINT
by flushing). Finally, the item regarding optimizing chunky searching
is irrelevant since we dropped chunky searching in favor of the much
better streamed searching.
When "notmuch show" was recently modified to not show an entire thread
by default, it also lost all capability to properly order the messages
in a thread and to print their proper depth. For example, the command:
notmuch show thread:6d5e3e276461188c5778c9f219f63782
had dramatically different output than:
notmuch show --entire-thread thread:6d5e3e276461188c5778c9f219f63782
even though both commands were selecting and displaying the same set
of messages. The first command would diplay them "flat", (all with
depth:0), and in strict date order; while the second command would
display them "nested" (with depth based on threading), and in thread
order.
We now fix "notmuch show" without the --entire-thread option to also
display nested and thread-ordered messages.
If some messages in the thread are not included in the displayed
results, then they are not counted when computing depth values.
This patch changes the default behaviour of notmuch show to display only
messages that match the search expression. However, --entire-thread
option is provided to display all messages in threads that matched the
search expression.
It is deemed that will be more useful for human users on the command line.
Scripts can be modified to include the --entire-thread option so that they
can display all messages once more.
Example:
$ notmuch search subject:git AND thread:23d99d0f364f93e90e15df8b42eddb5b
thread:23d99d0f364f93e90e15df8b42eddb5b July 31 [4/12] Johan Herland; [RFCv2 00/12] Foreign VCS helper program for CVS repositories (inbox unread)
Note that in this thread 4 out of 12 messages matched. The default show
behaviour is to show only those messages that match:
$ notmuch show subject:git AND thread:23d99d0f364f93e90e15df8b42eddb5b | grep 'message{' | wc -l
4
With the --entire-thread option the output will contain all dozen
messages:
$ notmuch show --entire-thread subject:git AND thread:23d99d0f364f93e90e15df8b42eddb5b | grep 'message{' | wc -l
12
Signed-off-by: Bart Trojanowski <bart@jukie.net>
The environment variables CC and CXX can be set at configure time to
specify what compiler to use. This compiler will be used for any
configure-time compilation, and will also be recorded in
Makefile.config to be used during the actual build.
The compiler to be used can still be overridden at build time by using
a make variable such as:
make CC=gcc
Each dependency now gets its own variable in the resulting
Makefile.config to make it much easier to debug where the various
flags came from in the case of any problems.
It's probably a bit more work to use this configure script without
pkg-config, but it's at least possible, (and we could make it even
easier if this becomes an important use case).
Previously, we were resolving these within the Makefile. This had
the problem that if pkg-config was not present, the Makefile would
still invoke it resulting in ugly errors before the configure script
was even run, (which would finally present a kind error message about
pkg-config not being present).
This keeps configure-related clutter out of the main directory, and
also gives a more direct correlation between the name of the test and
the feature being tested for.
Some compilers complain that result might be used uninitialized in
this function. I believe such compilers simply aren't looking hard
enough, but it's easy enough to silence them.
Some systems have an echo implementation which doesn't know how to
interpret a sequence of "\n". The word is that printf should be much
more portable, so let's try that instead.
We're now using printf to print what we're checking before we check. We're
also making variables such as HAVE_GETLINE available to both make and to
the C pre-processor.
With this, the local getline implementation is now only compiled if not
available on the system.
Add a simple test to the configure script to detect getline. It's not
important that the test run, just that it compiles and links without
any errors.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
We were missing an "override" directive in the assignment of CFLAGS
within Makefile.config so it was actually having no effect. Then, we
were also failing to get the proper include path for valgrind.h so
it wouldn't have worked even it were having effect. Fix both problems.
These were copied from the gnulib git repository as of:
commit 563c779682040ed4b89c9b4bbe428dcd8157c90a
They come under the GNU GPL v3 (or later) exactly as notmuch is
licensed.
Since we need to do this for portability, (some systems don't have a
strndup function), we might as well do it unconditionally. There's
almost no disadvantage to doing so, and this has the advantages of not
requiring a configure-time check nor having two different
implementations, one of which would often be less tested.
We carefully noted the fact that we had locally allocated the string
here, but then we neglected to free it. Switch to talloc instead
which makes it easier to get the behavior we want. It's simpler since
we can just call talloc_free unconditionally, without having to track
the state of whether we allocated the storage for name or not.
We had avoided using "echo -n" originally for portability concerns,
and instead just printed the same string in both conditions, (and
also printed the string late if any check took long). The word is
that printf is quite portable, so we use that instead.
It was problematic to have this in "make install" since it would
unconditionally try to install to /etc, (even if a non-privileged user
was attempting an install to a prefix in the user's home directory,
for example).
If the user is explicitly providing EOF, then terminating the program
is the most likely desired thing to do. This also avoids undefined
behavior from continuing with an uninitialized response after ignoring
the return value of getline().
Glibc (at least) provides the warn_unused_result attribute on write,
(if optimizing and _FORTIFY_SOURCE is defined). So we explicitly
ignore the return value in our signal handler, where we couldn't do
anything anyway.
Compile with:
make CFLAGS="-O -D_FORTIFY_SOURCE"
before this commit to see the warning.
This makes these keys different than 'q' in this mode, (where 'x'
and 'q' are identical in all of the other modes currently).
The idea here is to make it easier to do non-linear reading of messages,
(such as when poking in to read just one or two threads from a search
result that returned many threads).
The dynamic scoping of emacs lisp is such that we never want to assign
to any variable unless it's something we've defined with `defvar' or
else something we're using locally via `let'.
Our documentation is long enough that I think it will be more useful
to use an entire window for it (which is easily dismissed with 'q').
This is also kinder for a user not well-initiated with emacs, for
whom the multi-window help can be confusing.
Previously, we had some hard-coded keybindings mentioned in the
introductory paragraphs of the documentation for notmuch-search-mode.
Now, we take advantage of the substitute-command-keys functionality to
produce the same text by default, but to dynamically generate the
correct text in the face of the user customizing the keybindings.
As we did recently for notmuch-search-mode-map, ensure that the first
line of docuemntation for each command stands alone.
We also take advantage of the substitute-command-keys functionality
within notmuch-help so that the introductory paragraphs can talk
about key bindings by key (rather than function name) in a way that
will always be current even in the face of the user rebinding keys.
Previously, we would do only a single-level traverse of the keymap.
That meant that for a keybinding such as "M-TAB" we would just see
the prefix key ("ESC") and print that it was a keymap---never printing
the TAB nor the documentation for the command it is bound to.
Now, we do the full walk, constructing a proper description of the
full keybdinding with prefix characters, (and converting "ESC" to
"M-" for legibility).
