Generally, the NEWS items will describe changes since the previous
release. But there's not much we can do for that since we've never had
a release before.
Initially this file provides one main function
notmuch-query-get-threads, which takes a set of search terms, and
returns a parsed set of matching threads as a lisp data structure.
A set of notmuch-query-map-* functions are provided to help map
functions over the data structure.
The function notmuch-query-get-message-ids uses this machinery to get
the set of message-ids matching a query.
Edited-by: Carl Worth <cworth@cworth.org>: Change comment syntax,
(";;" rather than ";" to make emacs-lisp mode happy), and eliminate
some excess whitespace, as suggested by David Edmonson.
To ease the transition to a JSON based implementation of
`notmuch-show', move the current implementation into a separate file.
Create `notmuch-lib.el' to hold common variables.
Assume that tags never include an opening bracket, and hence improve
the regular expression used to highlight them. This avoids false
matches where the 'from' address of a thread participant includes an
opening bracket.
We add a magic line to the beginning of each Makefile.local file to
help the editor know that it should use makefile mode for editing the
file, (even though the filename isn't exactly "Makefile").
Edited-by: Carl Worth <cworth@cworth.org>: Expand treatment from
emacs/Makefile.local to each instance of Makefile.local.
Reviewed-by: Carl Worth <cworth@cworth.org>: Presumably, this is to
enable proper building in the very near-term future where the emacs
implementation consists of multiple files where some will `require'
functions from others.
It was getting quite annoying to see this big block of text on every
little build, (but I didn't want to get rid of it for any new users).
This seems to strike the right balance.
I don't really know why we ended up having everything indented by two
tabs, (perhaps trying to make it match the man page)? But wihout any
containing context to justify that it just looks odd.
The output was far too busy otherwise. It's more useful to just
show the argument list in the case of "notmuch help <command>"
for a specific command.
(Credit due to running "git help" and seeing a much more readable
list than what was coming out of "notmuch help".)
Previously, only "notmuch help" worked while a call to "notmuch --help"
would just print a message telling the user to call "notmuch help".
Instead of the redirection, just support --help directly now.
A new 'part' subcommand allows the user to extract a single part from
a MIME message. Usage:
notmuch part --part=<n> <search terms>
The search terms must match only a single message
(e.g. id:foo@bar.com). The part number specified refers to the part
identifiers output by `notmuch show'. The content of the part is
written the stdout with no formatting or identification marks. It is
not JSON formatted.
Include a 'date_unix' and 'date_relative' field in the JSON output for
each message. 'date_relative' can be used by a UI implementation,
whereas 'date_unix' is useful when scripting.
The idea here is to allow a new user of notmuch to be able to run
notmuch immediately after compiling, (without having to install
the shared library first). This also ensures that the test suite
tests the locally compiled library, and not whatever installled
version of the library the dynamic linker happens to find.
I ran into this while looking at the vim plugin. Vim's system() call
redirects output to a file and it was missing many of the part{ lines.
If stream_stdout is setup too early, it will overwrite the part start
when notmuch is redirected to a file.
Reviewed-by Carl Worth <cworth@cworth.org>: GMime is calling fseek
before every write to reset the FILE* to the position it believes is
correct based on the writes it has seen. Our code was getting
incorrect results because our GMime writes were interleaved with
non-GMime writes via printf.
The bug appears when writing to a file because it's seekable, but not
when writing to a pipe which is not.
When I wanted to create a debian package from the current master, make
install failed because of non-existent include directory. This patch
fixes this minor issue.
The default "make" would be quite quiet, but still conveniently print
the CFLAGS. The explicit "make V=0" was intended to be identical, (only
not printing the message about V=1 but was broken in that it left the
CFLAGS off). Fix this.
We had a fairly ugly violation of modularity with the top-level
Makefile.local isntalling everything, (even when the build commands
for the library were down in lib/Makefile.local).
One of the supproted mechanisms we offer for configuration is
manually editing the Makefile.config file after it is generated
by the configure script. In this case it would be nice to be able
to change prefix only once, so allow that.
There's not any special configure logic for determining these variable
values, but if we did add some in the future, then these will now be
in the right place for that.
Additionally, this now makes Makefile.local the single place for the
user to look for manually tweaking a variable assignment, (say, for a
compiler that can't accept a particular warning argument).
With this change, there should rarely be any need for a user to poke
into any Makefile.local file.
Before it was impossible to know whether any particular setting or
rule definition was in Makefile or Makefile.local. So we strip the
Makefile down to little more than the list of sub-directories and
the logic to include all of the sub-directories' Makefile.local
fragments.
Then, all of the real work can happen inside of Makefile.local.
If an explicit --libdir is passed, then that is used directly. Otherwise
libdir is chosen as the value of $PREFIX/lib, (whether or not prefix was
passed explicitly or set by default).
For the case of adding a file that already exist, (with the same
filename). In this case, nothing will happen to the database, but
that wasn't clear before.
When trying to restore the current position, if the "current" thread
no longer appears in the buffer, then '=' moves to the current line
instead. When near the end of the buffer, the "current" line should
be counted as the number of lines from the end.
I just tried (and failed) to write a test for the recent magic
inference of phrase searches. That's a feature that makes me *really*
uncomfortable to not have an automated test. But I believe the
proposed modularization of the test suite should reduce some quoting
nightmares, so will hopefully make this easier.
These results have all the same terms as the target phrase, but
not in the expected order. They are designed to ensure that we
actually test phrase searches.
And as it turns out, we're not currently quoting the search terms
properly, so the phrase-search tests now fail with this commit.
The previous json patches forgot to add the notmuch tags to the json
output. This is inconsistent to the text output so here they are. We
just output a 'tags' field that sends notmuch tags as a json array.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We currently allow the cursor to be positioned on the "End of search
results" line after the last thread in a search buffer. When
refreshing on this line, there's no thread ID to be used as the
target.
Previously, a refresh from this case would result in a nil thread
target, but we were also using nil to indicate that the target thread
had been found. This caused the position to be lost during refresh,
(the cursor would move from the last line in the buffer to the first).
We fix this by using a magic string of "found" rather than nil to
clearly indicate whether the target thread has actually been found.
It doesn't make sense to move the cursor to some random point in the
middle of a line. We always want the refresh to leave the cursor at
the beginning of some line instead.
