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.
Notmuch cli provides all structured data previously provided
in json format now in s-expression format, rendering all current
json functionality obsolete.
This removes the v command, since we now have much nicer part commands,
and deprecates the underlying notmuch-show-view-all-mime-parts. This
also means that people who try using the old unprefixed 'v' command on
a part button will no longer be greeted by ALL of their parts popping
up.
Previously the query string for piping a message to a command was
"Pipe message to command: " regardless of whether the function was
called with a prefix argument (which pipes all open messages to the
command). This patch modifies the `interactive' command to reflect
this.
This adds the actual code to do the lazy insertion of hidden parts.
We use a memory inefficient but simple method: when we come to insert
the part if it is hidden we just store all of the arguments to the
part insertion function as a button property. This means when we want
to show the part we can just resume where we left off.
One thing is that we can't tell if a lazy part will produce text until
we try to render it so when unhiding a part we check to see if it
rendered; if not we invoke the default part handler (e.g. an external
viewer).
Also, we would like to insert the lazy part at the start of the line
after the part button. But if this line has some text properties
(e.g. the colours for a following message header) then the lazy part
gets these properties. Thus we start at the end of the part button
line, insert a newline, insert the lazy part, and then delete the
extra newline at the end of the part.
Previously, whether a part was hidden or shown was recorded in the
invisibility/visibility of the part overlay. Since we are going to
have lazily rendered parts with no overlay store the hidden/shown
state in the part button itself.
Additionally, in preparation for the invisible part handling move the
actual hiding of the hidden parts to insert-bodypart from
create-part-overlays.
Finally, we will need to know whether a part-insertion has done
anything (it won't if the invisible part cannot be displayed by emacs)
so we slightly rejig the code order in
notmuch-show-toggle-part-invisibility to make it easier for the
function to set an appropriate return value.
Previously each of the part insertion handlers inserted the part
button themselves. Move this up into
notmuch-show-insert-bodypart. Since a small number of the handlers
modify the button (the encryption/signature ones) we need to pass the
header button as an argument into the individual part insertion
handlers. However, the declared-type argument was only used for the
text for the part buttons we can now omit it.
The patch is large but mostly simple. The only things of note are that
we let the text/plain handler applies notmuch-wash to the whole part
including the part button. In particular, notmuch-wash removes leading
blank lines from a text/plain part, but since the button is counted as
part of the part this does not happen with text/plain buttons that
have a button. This is probably a bug in notmuch-wash but changing it
does make several tests fail (that rely on this blank line) so, for
the moment, keep the old behaviour.
Earlier patches have moved the handling of wash fake inline patch
parts to insert-bodypart so we can drop the function
notmuch-show-insert-part-inline-patch-fake-part
Previously, we simply called pushnew to add :notmuch-part to the
front-sticky and rear-nonsticky text property lists. This works if
these are nil or lists, but they can also have the value t, meaning
that all properties are front-sticky/rear-nonsticky. In this case,
pushnew will signal an error because t is not a list. We never set
these properties to t ourselves, but since we apply these property
changes over arbitrary renderer output, we have to deal with this
possibility.
Several function docstrings refer to behaviour in docstrings that is
really controlled by notmuch-archive-tags. Add cross references, and
replace hardcoding.
These functions refer to default values of variables, but it seems
less confusing and less likely to get out of date to just allow the
user to follow the help cross-reference links.
I found several places where a setq is immediately followed by a let
or a let*. This seems to be the pessimal combination, with the
implicit scope of the setq combined with the extra indentation of the let.
I combined these cases into a single let* which I think is easier to read.
I can't see any benefit to the funcall, and it looks like the result
of cut-and-paste from some code that actually used a variable for the
function to call.
Since the part commands are no longer tied to a button, but can be
applied with point anywhere within a part, bind the part commands
keymap to "." everywhere in the show buffer. This lets you save or
view parts without having to navigate to the part button, and is
particularly useful for parts that have no button.
This removes the un-prefixed MIME part commands from the part button
keymap, but that's okay because those clashed in annoying ways with
show buffer bindings like "s" for search. RET on part buttons is
unaffected, which is the most important part button binding.
This unifies the part button actions and the underlying part action
functions into single interactive command that simply applies to the
part containing point using the just-added part p-list text property
instead of button properties. Since all part actions can be performed
by applying the appropriate mm function to an mm-handle, this patch
abstracts out the creation of mm handles, making the implementations
of the part commands trivial. This also eliminates our special
handling for part save in favor of using the appropriate mm function.
This necessarily modifies the way we handle the default part button
action, but in a way that does not change the meaning of the
notmuch-show-part-button-default-action defcustom.
Since these commands are no longer specific to buttons, this patch
eliminates the extra metadata stored with each button. This also
eliminates one rather special-purpose macro for a collection of
general purpose part handling utilities.
This is similar to what we already do with the message p-list, though
we apply the part's text property to the whole part's text, in
contrast with the message p-list, which is (rather obscurely) only
applied to the first character.
Previously, we lost any text properties applied to part buttons or
wash buttons when they were toggled because `insert' directly copies
the text properties of the string being inserted. Fix this by
capturing the properties applied to the button beforehand and
re-applying them after inserting the new text.
Previously, notmuch-show-view-part overrode the function binding of
mm-show-part to redirect it to notmuch-show-save-part to get notmuch's
default file name handling in case mm-display-part decided to fall
back to saving the part. In addition to being messy, this depended on
the now-deprecated dynamic binding behavior of flet.
This patch removes the mm-show-part override in favor of passing the
file name in to mm-show-part the way it expects, so we get its default
file name handling. It's not clear why we didn't do this before;
mm-show-part has supported default file names since at least Emacs
23.1.
Currently mime parts are basically handled based on their mime-type
with the exception of application/octet-stream parts. Deal with these
parts at the top level (notmuch-show-insert-bodypart).
This is needed later in the series as we need to put in a part button
for each part (which means knowing its mime type) while deferring the
actual insertion of the part.
Some (declare-function ...) definitions were drifted away from the
actual (defun ...)'s. To find the drifts and to verify changes
the following command line was used:
$ emacs --batch -L emacs --eval '(check-declare-directory "emacs")'
This patch extracts the rendering of tags in notmuch-show to
the notmuch-tag file.
This file introduces a `notmuch-tag-formats' variable that associates
each tag to a particular format. This variable can be customized
thanks to the work of Austin Clements. For example,
'(("unread" (propertize tag 'face '(:foreground "red")))
("flagged" (notmuch-tag-format-image tag "star.svg")))
associates a red foreground to the "unread" tag and a star picture to
the "flagged" tag.
Signed-off-by: Damien Cassou <damien.cassou@gmail.com>
Emacs has two button type objects: widgets (as used for saved searches
in notmuch-hello) and buttons as used by parts/citations and id links
in notmuch-show. These two behave subtly differently when clicked with
the mouse: widgets select the window clicked before running the
action, buttons do not.
This patch makes all of these behave the same: clicking always selects
the clicked window. It does this by defining a notmuch-button-type
supertype that the other notmuch buttons can inherit from. This
supertype binds the mouse-action to select the window and then
activate the button.
There is a bug in the current notmuch code with w3m and invisible
parts. w3m sets a keymap, and if we have a hidden [text/html] point
at the start of the following line still gets this w3m keymap which
causes some strange effects. For example, RET gives an error "No URL
at Point" rather than hiding the message, <down> goes to the next link
rather than just down a line.
These keybinding are also inconvenient when the text/html part is
displayed so we ask w3m not to install a keymap.
This is only likely to be a problem for emacs 23 as shr is preferred
as html renderer on emacs 24 (although the user can set the renderer
to w3m even on emacs 24).
This solution was suggested by Tomi Ollila <tomi.ollila@iki.fi>
Now that the invisibility display of parts is present we no longer
need to force the display of all multipart/alternatives: users can
toggle them for themselves when needed.
This adds a button action to show hidden parts. In this version "RET"
toggles the visibility of any part which puts content in the buffer
(as opposed to attachments such as application/pdf).
The button is used to hide parts when appropriate (eg text/html in
multipart/alternative).
This makes notmuch-show-insert-bodypart add an overlay for any
non-trivial part with a button header (currently the first text/plain
part does not have a button). At this point the overlay is available
to the button but there is no action using it yet.
In addition the argument HIDE is passed down to
notmuch-show-insert-part-overlays to request that the part be hidden
by default but this is not acted on yet.
This just make notmuch-show-insert-part-header save the basic button
text for parts as an attribute. This makes it simpler for the button
action (added in a later patch) to reword the label as appropriate (eg
append "(not shown)" or not as appropriate).
Previously, all visibility in show buffers for headers, message
bodies, and washed text was specified by generating one or more
symbols for each region and creating overlays with their 'invisible
property set to carefully crafted combinations of these symbols.
Visibility was controlled not by modifying the overlays directly, but
by adding and removing the generated symbols from a gigantic buffer
invisibilty spec.
This has myriad negative consequences. It's slow because Emacs'
display engine has to traverse the buffer invisibility list for every
overlay and, since every overlay has its own symbol, this makes
rendering O(N^2) in the number of overlays. It composes poorly
because symbol-type 'invisible properties are taken from the highest
priority overlay over a given character (which is often ambiguous!),
rather than being gathered from all overlays over a character. As a
result, we have to include symbols related to message hiding in the
wash code lest the wash overlays un-hide parts of hidden messages. It
also requires various workarounds for isearch to properly open
overlays, to set up buffer-invisibility-spec for
remove-from-invisibility-spec to work right, and to explicitly refresh
the display after updating the buffer invisibility spec.
None of this is necessary.
This patch converts show and wash to use simple boolean 'invisible
properties and to not use the buffer invisibility spec. Rather than
adding and removing generated symbols from the invisibility spec, the
code now directly toggles the 'invisible property of the appropriate
overlay. This speeds up rendering because the display engine only has
to check the boolean values of the overlays over a character. It
composes nicely because text will be invisible if *any* overlay over
it has 'invisible t, which means we can overlap invisibility overlays
with abandon. We no longer need any of the workarounds mentioned
above. And it fixes a minor bug for free: now, when isearch opens a
washed region, the button text will update to say "Click/Enter to
hide" rather than remaining unchanged.
Previously refreshing the notmuch show buffer did not remove overlays
which meant that if the user refreshed a message with images the
images would remain and then the new text was added after.
One might have guessed that erase-buffer would have removed them but
it seems not. Thus force the removal of overlays with remove-overlays.
This function is also used by pick so split it out in preperation for
moving to lib. In fact, pick and show want a slightly different
combination of name and email on return so make the separated function
return them as a pair, and let show or pick extract the combination
they want from that.
The macro with-current-notmuch-show-message executes command
`notmuch show --format=raw id:...` which just outputs the contents
of the mail file verbatim (into temporary buffer). In case e.g. utf-8
locale is used the temporary buffer has buffer-file-coding-system as
utf-8. In this case Emacs converts the data to multibyte format, guessing
that input is in utf-8.
However, the "raw" (MIME) message may contain octet data in any other
8bit format, and as no (MIME-)content spesific handling to the message
is done at this point, conversion to other formats may lose information.
By setting coding-system-for-read 'no-conversion drops the conversion part
and makes this handle input as notmuch-get-bodypart-internal() does.
This marks the broken test in previous change fixed.
icalendar-import-buffer can fail by an error signal (which have been
witnessed) but according to its docstring it can also return nil
when failing (it returns t when succeeding).
Now that the error is caught by the caller of notmuch-show-inset-part-*
functions in case icalendar-import-buffer returns nil an explicit
error is signaled and unwind-protect takes care of deleting the
temporary file (just in case, it is usually not written to the fs yet).
notmuch-get-bodypart-content provides raw data to its caller so
that it can be stored verbatim whenever needed. icalendar functions
expect Emacs to do EOL conversion for the data given to these. Therefore
it the CRLF -> LF conversion is now done explicitly.
The calls to private functions icalendar--convert-ical-to-diary and
icalendar--read-element are replaced with call to public function
icalendar-import-buffer.
This regexp agrees with Xapian query syntax much more closely, though
we specifically disallow various cases that would be confusing in the
context of an email body (e.g., punctuation at the end of an id: link
is not considered part of the id: link because it's probably part of
the surrounding text).
In particular, this handles id: links that are not surrounded by
quotes much better, which stash is much more likely to generate now
that we don't quote id's that don't need to be quoted. It also
handles quoted id: links better.
We update the buttonization test to reflect the new pattern.
When inserting of email bodypart failes, insert a failure message
to the buffer (and continue) instead of halting the insertion of
the rest of that email thread in question.
Since marking a message as read can now be a user customized set of
tag changes, make reversing this easier. Allow a prefix argument to
notmuch-show-mark-read to reverse the marking as read, similar to the
unarchiving in notmuch-show-archive-message.
While at it, update the relevant documentation to match that of other
automatic tagging (i.e. archive and reply).
Add support for customization of the tag changes that are applied when
a message or a thread is archived. Instead of hard-coded removal of
the "inbox" tag, the user can now specify a list of tag changes to
perform.
The `notmuch-show-mark-read-tags' lists tags that are to be applied when
message is read. By default, the only value is "-unread" which will remove
the unread tag. Among other uses, this variable can be used to stop
notmuch-show from modifying tags when message is shown (by setting the
variable to an empty list).
Previously, notmuch-show-previous-message would move to the beginning
of the message before the message containing point. This patch makes
it instead move to the previous message *boundary*. That is, if point
isn't already at the beginning of the message, it moves to the
beginning of the current message. This is consistent with
notmuch-show-next-message, which can be thought of as moving to the
next message boundary. Several people have expressed a preference for
this.
The pipe message function (when used with a prefix) uses a search of
the form "id:<id1> or id:<id2>" etc. Since the user says precisely
which messages are wanted by opening them it should not use excludes.
