We've received a user report that the hidden citations were annoying
since the user couldn't tell what was being referred to by subsequent
text. Apparently it wasn't obvious enough that the hidden citation
could be revealed by clicking or by pressing Enter. So make the button
text say as much.
In the message mentioned in the previous commit, an ASCII diagram was
included in which '>' was used as the first non-whitespace character
in a line. Notmuch previously (and mistakenly) regarded this as a
citation.
We fix this by only regarding a '>' in the first column of an email as
introducing a citation.
Thanks to Dirk Hohndel for reporting the bug. The infinite loop was first
noticed in the following message (available from the Linux kernel mailing list):
alpine.LFD.2.00.0912081304070.3560@localhost.localdomain
Note that the bug does not show up when viewing the message in
isolation---the bug was triggered only when viewing this file indented
to a depth of at least 13.
The fix is simply to use a marker rather than an integer position when
recording a point we plan to move back to later, (since inserting the
indented button causes the buffer position of the desired marker to
change).
Previously only mime parts that indicated specified a "disposition" of
"attachment" were saved. However there are time when it is important
to be able to save inline content as well. After this commit any mime
part that specifies a filename will be considered when saving
attachments.
Similar to the way thread-viewing was broken after a thread was
archived, (and recently fixed), tag manipulation has also been broken
when the thread no longer matches the current search.
This also means that the behavior of '+' and '-' are now different
than that of '*'. The '+' and '-' bindings now return to the previous
behavior old affecting all messages in the thread, (and not simply
those matching the search).
I actually prefer this behavior, since otherwise a '-' operation on a
thread might not actually remove the tag from the thread, (since it
could operate on a subset of the thread and not hit all messages with
the given tag).
So I'd now like to fix '*' to be consistent with '+' and '-', for
which we add an item to TODO.
This fixes the annoying bug of archiving a thread, and then going back
to open it and getting an error. It needs the notmuch-show API
changing patch of 1259979997-31544-3-git-send-email-david@tethera.net.
Also modify the one call to notmuch-show in notmuch.el. This makes
the call (notmuch-show thread-id) will work when there is no binding
for notmuch-search-query-string; e.g. when called from user code
outside notmuch.
Add functions notmuch-search-find-authors and notmuch-find-subject to
match notmuch-find-thread-id. These functions are just a wrapper
around get-text-property, but in principle that could change.
This would provide support for "muted" threads, as well as allowing for negative
filtering based on messages not matched by the original search, (but present in
threads that do have at least one matched message).
The function _notmuch_message_add_thread_id has been removed
from the private interface of notmuch. There's no reason for
one to keep a declaration of its prototype in the code base.
Also, lets update a commentary that referenced that function
and escaped from previous scrutiny.
Signed-off-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
This reverts commit ed16edc94d.
The performance hit is just far too severe, (threads with many HTML
messages make emacs stop and pause for seconds before displaying the
thread even if most of the HTML messages are entirely hidden).
We have a bootstrapping issue with our dependency generation. When the
Makefile.config doesn't exist yet, the complete compilation flags are
not yet available for passing to the compiler to generate the
dependencies.
But we don't have explicit rules to create these dependency files,
(just the implicit rule that is created by the -include), so we can't
control when make will attempt to create them.
We do have a dependency of the dependency files on Makefile.config, so
make should eventually call the compiler with the correct flags and
everything should be good. So in the meantime, silence any complaints.
If the Makefile does this for the user, then no arguments are passed. So
it's only polite to let the user know that it's possible to get pass those
arguments.
These variables can now be set via configure time via environment
variables like so:
CFLAGS=-g ./configure
and subsequent builds will remember these values. The values can
still be overridden at compile time by passing make variables:
make CFLAGS=-O2
The CXXFLAGS variable is optional. If unset at either configure
time or at compile time, it will inherit its value from the
CFLAGS variable. (Though if explicitly set at configure time
it must be explicitly overriden at compile time---just overriding
CFLAGS will not override CXXFLAGS as well.)
The only reason I ever call "make V=1" myself, (other than when
debugging the compiler command-line for some reason), is to ensure
whether my CFLAGS, (like "-g -O0" or "-O2"), are actually making it to
the command-line.
But these are hard to find in the V=1 output, and really, we should
just print these even in the quiet case. So do that.
Reviewed-by: Carl Worth <cworth@cworth.org>:
This is really the fundamental thing that people expect a configure
script to do, so it's important to support it.
notmuch-search-filter now accepts an arbitrary query and will group if
necessary so that we get
tag:inbox AND (gravy OR biscuits)
instead of the former
tag:inbox AND gravy OR biscuits
Signed-off-by: Jed Brown <jed@59A2.org>
Add some text on how to install dependencies with yum for Fedora or
other systems that use yum for package management. Since the named of
the required packages on Fedora are slightly different from Debian
this will help get new users of notmuch that use Fedora going quicker.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
Pass the message through the charset filter so that we can view
messages wrote in different charset encoding.
Signed-off-by: Kan-Ru Chen <kanru@kanru.info>
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).
