This simplifies the traversal of regions of results and eliminates the
need for save-excursions (which tend to get in the way of maintaining
point when we make changes to the buffer). It also fixes some strange
corner cases in the old line-based code where results that bordered
the region but were not included in it could be affected by region
commands. Coincidentally, this also essentially enables multi-line
search result formats; the only remaining non-multi-line-capable
functions are notmuch-search-{next,previous}-thread, which are only
used for interactive navigation.
Now that we keep the full thread result object, we can refresh a
result after any changes by simply deleting and reconstructing the
result line from scratch.
A convenient side-effect of this wholesale replacement is that search
now re-applies notmuch-search-line-faces when tags change.
Previously, tag-based search result highlighting was done by creating
an overlay over each search result. However, overlays have annoying
front- and rear-advancement semantics that make it difficult to
manipulate text at their boundaries, which the next patch will do.
They also have performance problems (creating an overlay is linear in
the number of overlays between point and the new overlay, making
highlighting a search buffer quadratic in the number of results).
Text properties have neither problem. However, text properties make
it more difficult to apply multiple faces since, unlike with overlays,
a given character can only have a single 'face text property. Hence,
we introduce a utility function that combines faces into any existing
'face text properties.
Using this utility function, it's straightforward to apply all of the
appropriate tag faces in notmuch-search-color-line.
notmuch-message-mark-replied used "apply" to change message tags
according to notmuch-message-replied-tags after sending a reply. This
works if the latter is a single-element list. But with the recently
changed format of tag changes, it breaks for multiple-element lists.
Use "funcall" to properly pass the list of tag changes as a single
argument.
The JSON format eliminates the complex escaping issues that have
plagued the text search format. This uses the incremental JSON parser
so that, like the text parser, it can output search results
incrementally.
This slows down the parser by about ~4X, but puts us in a good
position to optimize either by improving the JSON parser (evidence
suggests this can reduce the overhead to ~40% over the text format) or
by switching to S-expressions (evidence suggests this will more than
double performance over the text parser). [1]
This also fixes the incremental search parsing test.
This has one minor side-effect on search result formatting.
Previously, the date field was always padded to a fixed width of 12
characters because of how the text parser's regexp was written. The
JSON format doesn't do this. We could pad it out in Emacs before
formatting it, but, since all of the other fields are variable width,
we instead fix notmuch-search-result-format to take the variable-width
field and pad it out. For users who have customized this variable,
we'll mention in the NEWS how to fix this slight format change.
[1] id:"20110720205007.GB21316@mit.edu"
This parser is designed to read streaming JSON whose structure is
known to the caller. Like a typical JSON parsing interface, it
provides a function to read a complete JSON value from the input.
However, it extends this with an additional function that
requires the next value in the input to be a compound value and
descends into it, allowing its elements to be read one at a time
or further descended into. Both functions can return 'retry to
indicate that not enough input is available.
The parser supports efficient partial parsing, so there's no need to
frame the input for correctness or performance.
The bulk of the parsing is still done by Emacs' json.el, so any
improvements or optimizations to that will benefit the incremental
parser as well.
Currently only descending into JSON lists is supported because that's
all we need, but support for descending into JSON objects can be added
in the future.
This advises the search process filter to make it process one
character at a time in order to test the pessimal case for incremental
search output parsing.
The text parser fails this test because it gets tricked into thinking
a parenthetical remark in a subject is the tag list.
Rather than passing lots of arguments and then further passing those
to `notmuch-search-insert-field', pass a plist containing all of the
search result information. This plist is compatible with the JSON
format search results.
This is a simpler place to do this, since we can avoid any point
motion and hence any save-excursions in
`notmuch-search-process-filter', which in turn lets us put all of the
search-target logic outside of any save-excursions.
`notmuch-search-show-{result,error}' are now responsible for their own
point motion.
`notmuch-search-process-filter' could use some reindentation after
this, but we're about to rewrite it entirely, so we won't bother.
This removes the last bit of direct output from the parsing function.
With the parser now responsible solely for parsing, we can swap it out
for another parser.
Previously, much of the display of search lines was done in the same
function that parsed the CLI's output. Now the parsing function only
parses, and notmuch-search-show-result fully inserts the search result
in the search buffer.
The initial nmbug-status was pretty consistent in it's whitespacing
but a few lines had some leftover slips. Those are now "corrected".
Also, most of the code used ' as quoting char. As in Python one can
use ' and " interchangeably some code used " instead of '. However
the usage of those were inconsistent. Now all quotes that python
parses are ':s (only quoted content uses ":s).
No functional changes.
In reformatting the line 111 accidentally indented to one indentation
level too much (happens easily when interactively indenting python
code using emacs). The line now has 4 spacess less indentation, thus
restoring it to the block level it belongs.
This is (almost) the same script as has been used for
http://nmbug.tethera.net/status for a while now. The only change is
that the configuration is not hardcoded anymore. By default the config
is fetched from a special branch in the nmbug repo that contains only
config info. The idea is that push access to this branch can be
restricted a bit more than the tags, since it will change the
appearence of the web pages.
The NAME section in manpages generally doesn't start with capital
letter (unless the word is 'proper noun') and doesn't end with
period. Notmuch manual pages now matches that "format".
There didn't seem to be these basic tests for --format=text,
as there are for --format=json. These are just the tests from
the `json' script, with adjusted expected outputs.
In id:"87sjdm12d1.fsf@awakening.csail.mit.edu" Austin pointed out that
devel/schemata needs a slight correction with the new
--entire-thread=false option. This is that correction.
This introduces a variable to control after how many characters a line
is wrapped by notmuch-wash-wrap-long-lines (still wrapping at the
window width if it is lower).
Previously the elide messages code got the entire-thread from
notmuch-show.c and then threw away all non-matching messages. This
version calls notmuch-show.c without the --entire-thread flag so
it never receives the non-matching messages in the first place.
This makes it substantially faster.
The --entire-thread option in notmuch-show.c defaults to true when
format=json. Previously there was no way to turn this off. This patch
makes it respect --entire-thread=false.
To do this the patch moves the --entire-thread option to be a keyword
option using the new command line parsing to allow the existing
--entire-thread to keep working.
All formats except Json can output empty messages for non
entire-thread, but in Json format we output "null" to keep the other
elements (e.g. the replies to the omitted message) in the correct
place.
This changes the parsing for "keyword" options so that if the option
is specified with no argument the argument is parsed as if it were
passed an empty string. This make it easier to add options to existing
boolean arguments (the existing --option can default to TRUE).
Some C compilers are stricter when it comes to (tentative) definition
of a variable -- in those compilers introducing variable without 'extern'
keyword always allocates new 'storage' to the variable and linking all
these modules fails due to duplicate symbols.
This is reimplementation of Charlie Allom's patch:
id:"1336481467-66356-1-git-send-email-charlie@mediasp.com",
written originally by Ali Polatel. This version has
more accurate commit message.
Allow the user to pipe the attachment somewhere. Bound to '|' on the
attachment button.
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
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>
Previously, notmuch new only synchronized maildir flags to tags for
files with a maildir "info" part. Since messages in new/ don't have
an info part, notmuch would ignore them for flag-to-tag
synchronization.
This patch makes notmuch consider messages in new/ to be legitimate
maildir messages that simply have no maildir flags set. The most
visible effect of this is that such messages now automatically get the
unread tag.
Previously, we synchronized flags to tags for any message that looked
like it had maildir flags in its file name, regardless of whether it
was in a maildir-like directory structure. This was asymmetric with
tag-to-flag synchronization, which only applied to messages in
directories named new/ and cur/ (introduced by 95dd5fe5).
This change makes our interpretation stricter and addresses this
asymmetry by only synchronizing flags to tags for messages in
directories named new/ or cur/. It also prepares us to treat messages
in new/ as maildir messages, even though they lack maildir flags.
This way notmuch_message_maildir_flags_to_tags can call it. It makes
more sense for this to be just above all of the maildir
synchronization code rather than mixed in the middle.
Currently, notmuch new only synchronizes maildir flags to tags for
files that have an "info" part. However, in maildir, new mail doesn't
gain the info part until it moves from new/ to cur/. Hence, even
though mail in new/ doesn't have an info part, it is still a maildir
message and thus has maildir flags (though none of them set).
The most visible effect of not synchronizing maildir flags for
messages in new/ is that newly delivered messages don't get the unread
tag (unless it is assigned by some other mechanism, like new.tags).
This patch does *not* modify the test for messages in cur/ that do not
have an "info" part. Unlike a message in new/, a message in cur/
without an info part is no longer a maildir message, and thus
shouldn't be subject to maildir flag synchronization.
This has the affect of lazily creating the crypto contexts only when
needed. This removes code duplication from notmuch-show and
notmuch-reply, and should speed up these functions considerably if the
crypto flags are provided but the messages don't have any
cryptographic parts.
Use this flag rather than depend on the existence of an initialized
gpgctx, to determine whether we should verify a multipart/signed. We
will be moving to create the ctx lazily, so we don't want to depend on
it being previously initialized if it's not needed.
This new structure, notmuch_crypto_t, keeps all relevant crypto
contexts and parameters together, and will make it easier to pass the
stuff around and clean it up. The name of the crypto context inside
this new struct will change, to reflect that it is actually a GPG
context, which is a sub type of Crypto context. There are other types
of Crypto contexts (Pkcs7 in particular, which we hope to support) so
we want to be clear.
The new crypto.c contains functions to return the proper context from
the struct for a given protocol (and initialize it if needed), and to
cleanup a struct by releasing the crypto contexts.
gmime 2.4 defines GMimeCipherContext, while 2.6 defines
GMimeCryptoContext. typedef them both to notmuch_crypto_context_t to
cover this discrepancy and remove a bunch of #ifdefs.
If any of the forked process exits with nonzero value, terminate
current operation -- nonzero exit value indicates failure and
then there is no point continuing.
