notmuch_message_get_header started returning some headers straight
from the database in 567bcbc, but this comment explicitly claimed all
headers were read from the message file.
Notmuch puts attachments in as declared content-type except when the
content-type is application/octet-stream it tries to guess the type
from the filename/extension. This means that viewing a pdf (for
example) which is sent as application/octet-strem invokes the pdf
viewer rather than just offering to save the part.
Recent changes to the attachment handling (commit 1546387d) changed
(broke) this. This patch stores the calculated mime-type with the part
and changes the attachment part handlers can use it instead.
Based on id:1370220299-14722-1-git-send-email-felipe.contreras@gmail.com
Hacked rather extensively by db. The most important changes:
- bring back notmuch.yaml for the (debian specific?) vim-addons
tool.
- depend on vim-ruby, so we get a version of vim with ruby installed.
Since this is in a disjunction, this should not force new packages to
be installed, but rather let people with auto-install-recommends (the
default) on install notmuch without emacs.
The 0.16 NEWS grew chronologically during development, and as a result
wound up in a particularly odd order. This rearranges it to put the
most user-visible news first. Roughly: new features, modified
behavior, bug fixes, then deprecation, with related items grouped.
This does not modify the text of any of the news.
Recently notmuch-hello was converted to use batch count. However, it
seems that several people run different versions of notmuch-emacs and
notmuch-cli so this batch makes emacs fail with an error message if
--batch is not available in the CLI.
Amended by: db
Badly formed messages that don't specify a protocol in
signed/encrypted parts, end up with a protocol of NULL. strcasecmp in
notmuch_crypto_get_context then segfaults when trying to check it
against known protocols. If the protocol is NULL, just return an
empty context immediately (with appropriate message.)
Notmuch cli provides all structured data previously provided
in json format now in s-expression format, rendering all current
json functionality obsolete.
The variable notmuch-pick-message-buffer should be buffer local but
instead notmuch-pick-message-buffer-name (a non-existent variable) was
made buffer local.
The function notmuch-pick-refresh-result (used to update tag changes)
was not quite correct: sometimes it got the choice between the subject
and " ..." wrong. This was always true but the new code often calls
this (when opening a message in the message pane to remove the unread
tag) while the async pick process is still running and this caused
mistakes which made the tests fail.
Thus we store the previous subject with the message.
This function was a horrible hack (sleeping while waiting for the
correct message). The new target code can just open the message in the
message window when it arrives.
The notmuch insert command reads a message from standard input,
writes it to a Maildir folder, and then incorporates the message into
the notmuch database. Essentially it moves the functionality of
notmuch-deliver into notmuch.
Though it could be used as an alternative to notmuch new, the reason
I want this is to allow my notmuch frontend to add postponed or sent
messages to the mail store and notmuch database, without resorting to
another tool (e.g. notmuch-deliver) nor directly modifying the maildir.
The 'insert' command will be better served if parse_tag_command_line
modifies a pre-populated list (of new.tags) instead of clobbering the
list outright. The sole existing caller, notmuch_tag_command, is
unaffected by this change.
Move an error condition specific to the 'tag' command out of
parse_tag_command_line so that parse_tag_command_line can be used for
the forthcoming 'insert' command.
This switches `notmuch-mua-reply' and `notmuch-query-get-threads' to
the S-exp format. These were the last two uses of the JSON format in
the Emacs frontend.
