This allows to have a function returning a window as value of
`mu4e-split-view`. I'm using this patch since quite some time locally with the
following function.
```el
(defun th/mu4e-split-view ()
(let* ((headers (mu4e-get-headers-buffer))
(headers-win (and headers (get-buffer-window headers)))
(view (mu4e-get-view-buffer))
(view-win (and view (get-buffer-window view))))
(cond
;; There's a view window, just use it.
(view-win view-win)
;; Just one window, split sensibly, i.e., horizontally or
;; vertically depending on geometry.
((one-window-p) (split-window-sensibly))
;; Otherwise, use the tallest window.
(t (car (sort (delq headers-win (window-list))
(lambda (a b)
(> (window-height a) (window-height b)))))))))
(setq mu4e-split-view #'th/mu4e-split-view)
```
Usurp more of the utils code than can be re-used without further dependencies in
helpers.
Split off specific parts in their own file.
After the helper/utils changes, update the rest of mu4e to take the changes into
account.
Split off the search functionality from mu4e-headers.el into a new
mu4e-search.el.
Clean up things a bit and create a minor mode in which to add the keybindings.
Enable this in main/headers/view.
Skip invisible text at BOL possibly hidden by
the end of another invisible overlay covering
previous EOL.
This patch affects people using mu4e-thread-folding-mode but change nothing
when using mu4e as it is.
This fixes the issue introduced by 50f6f539 where header navigation
would break when `visual-line-mode' was enabled. Previously,
`forward-line' was used in `mu4e-view-headers-next', which disregarded
visual lines and moved by logical lines, but this was changed to
`line-move', which moves by visual lines when `line-move-visual' is
non-nil (the default when `visual-line-mode' is enabled). Thus, when
the current header line was wrapped and a message was open in the
split view, `mu4e-view-headers-next' would move to the next visual
line in the headers buffer (the same message), and then jump back to
the start of the previous line, preventing switching to the next
message.
This would also throw off navigation when `mu4e-view-headers-next' was
used with a prefix argument, since it would move by visual lines and
not headers.
`line-move-visual' is therefore set to nil before using `line-move' to
prevent these issues.
This change is needed because forward-line doesn't honor this variable, more
generally visual lines.
Using `next-line` instead of `forward-line` allows this but it is more focused
on interactive use, so use `line-move` which handles visual lines without
warnings and return 0 or 1 just like `forward-line`.
When marking threads as read things are slowed down by echoing the
thread path to the mini-buffer. I assume this is left over debug but
if needed for something else should probably be a log call.
Make mu4e-view-use-gnus obsolete (it's the default now), and add a
variable mu4e-view-use-old (which must be set before starting mu4e).
Update documentation / mentions.
Load the correct view when starting mu4e, so people can customize
e.g. the keymap.
Add some sanity checking.
This wraps up some change that somehow didn't get applied when merging PR #1921
and also offers completion when editing a bookmark.
* mu4e/mu4e-headers.el (mu4e-headers-search): Read query with completion also
when editing a bookmark.
Make mu4e-personal-address-p safe for being called with nil.
Upgrade code that used mu4e-user-mail-address-p to
mu4e-personal-address-p.
Update docs.
Add some more helpers to mu4e-message, and avoid some byte-compiler
warnings.
Being able to pipe through shell from the headers view is
convenient for some use cases, so wire it up to work.
Resolves#1752
Signed-off-by: Jerry Snitselaar <jsnitsel@redhat.com>
Instead of a multi-step process to display an unread message (ie. get
the original, notice it's unread, then update it, replace the message
with update one etc.), we now handle that in the (view /./..) command on
the server side.
Simplifies things, and is faster (which could be noticeable, esp. if
e.g. signature verification is part of the process)
The code still has some problems, and the original author has moved
elsewhere (which is fine of course), but it's not ready enough for
1.4.... yet. So let's remove it for now and check again with 1.5+.
* mu4e/mu4e-headers.el (mu4e~headers-quit-buffer): Refresh main buffer
when done.
* mu4e/mu4e-main.el (mu4e-main-mode-map): Don't bind "g" to mu4e, "g"
should be bound to revert-buffer (special-mode).
(mu4e-main-mode): No need to specify map.
(mu4e~main-view-real-1): New.
(mu4e~main-redraw-buffer): New.
(mu4e~main-view-real): Use them.
(mu4e~main-view): Take one more arg REFRESH.
(mu4e~main-toggle-mail-sending-mode): revert-buffer when done.
Use "_" as the title of that section so that it is less distracting
when sections are collapsed to get an overview of the library.
Using a separate section is useful because it reduces the risk of
accidentally into the middle of a library.
Placing two semicolons on an otherwise empty line helps to logically
"connect" the surrounding "paragraphs", which in (only) some cases
makes sense.
Previously the three paragraphs of the permission statement were not
connected to each other like this, which is perfectly fine. However
the preceding "This file is not part of GNU Emacs." line was connected
to the first paragraph, which does not make sense considering that the
latter is not connected two the second paragraph, which it relates to
more.
Once those two semicolons are gone, it also makes sense to remove
those from the second line.
Previously both cl-lib.el and cl.el were used, now use only cl-lib.el.
Use lexical-binding where needed instead of requiring cl just for
`lexical-let`.
Replace some add-to-list with cl-pushnew as add-to-list is not
recommended in lisp program and anyway doesn't work properly with
lexical binding.
Highlighting target header is not working, when message view is selected and
mu4e-headers window is out of focus.
To fix this, call mu4e highlight function with mu4e-headers as current buffer.
While reading message using split view, search can be triggered after
automatic update and index. In this case, mu4e headers is not inside selected
window and mu4e-headers-goto-message-id fails to move window point of mu4e
headers.
To fix this, call set-window-point for mu4e headers window explitctly.
Re-use `mu4e-headers-thread-orphan-prefix' for the prefix for the
first sibling in the orphan thread and add
`mu4e-headers-thread-single-orphan-prefix' as the prefix of single orphans.
Added support for sorting by mailing-list; note that this ultimately is
a sort by the 'list-id', so the items will be in that alphabetical
order, which is not necessarily the same as the order of the friendly
names.
Update mu4e~headers-quit-buffer and mu4e~main-menu.
mu4e~headers-quit-buffer in single-window mode now kills current buffer
instead of quitting mu4e.
mu4e~main-menu is updated to redisplay the main menu on context switch
or unknown keybinding, display errors in commands better, and to handle
C-g and ESC keys.
Thanks to Joost Kremers for the suggestions.
Even though the user may be editing this expression there is no reason
to not have the mu4e~headers-search-hist present for the prompt. Emacs
will only replace it with system wide history which would likely
contain irrelevant history for the action.
Single-window mode is meant to minimize mu4e window operations (opening,
killing, resizing, etc) and buffer changes, while still retaining the
view and headers buffers. In addition, it replaces mu4e main view with a
minibuffer prompt containing the same information.
When the frame running mu4e is in another virtual desktop or iconified, but
still contains a visible headers buffer, do not attempt to create a new view.
Some fields (eg. :attachments and :user-agent) require a full message
and are not supported in headers-mode. Document this and give a clearer
error message when they are added to `mu4e-headers-fields'.
Fixes issue #933.
Now, when going to a message with certain message-id, do open a headers
buffer as well. This way, message opened this behave just like an other
message, and can be delete, flagged etc.
As a bonus, you get the whole message thread for a given
message (depending on settings)
mu4e-view-message-with-message-id now does a search and
mu4e-headers-search allow for some extra actions to open a specific
message in a hook function.
This was merged in as part of pull request #718 but changed to a more
general facility in 7716e00.
It's fantastic that we have the more general hook facility for any
search, but the primary use-case I had for the bookmark hook can't be
satisfied by the more general mu4e-headers-search-pre-hook.
The reason I added this hook was to emulate the folders I used in
Icedove as mu4e bookmarks. E.g. some folders are threaded, others are
not. By default mu4e only allows you to set this globally via options
like mu4e-headers-show-threads.
So I have a mu4e-headers-search-bookmark-hook which is basically a long
line of cond statements like:
((string-equal expr "NOT flag:trashed AND date:365d..now AND (flag:flagged)")
(setq mu4e-headers-show-threads nil)
(setq mu4e-headers-include-related nil)
(setq mu4e-headers-skip-duplicates t)
(setq mu4e-headers-results-limit 500))
For this to work properly it's critical that the hook doesn't execute on
any search, but *only* those where we enter it via the bookmark.
As an example, I have a "b+" search which finds messages I've flagged,
most of my searches have related & threading turned on, but for that
search I only want to show the specific messages I've flagged, so the
hook turns both of those settings off before executing the search.
But I might still want to change my mind and look at the related
messages as threads by pressing P and then W. This works with the
mu4e-headers-search-bookmark-hook because it only executes when we get
the search via a bookmark.
But it doesn't work with the mu4e-headers-search-pre-hook because when I
toggle the setting my settings hook (which matches the search executed
by the bookmark) will just turn it back off again.
Perhaps there's some clever way to know if we're getting to the
mu4e-headers-search-pre-hook via the bookmark that I've missed. But if
there isn't I need a hook that works like this.
Add `mu4e-compose-resend` to the menus in the headers and view
modes. Don't add a shortcut, as it's a fairly rarely needed feature, and
might be confusing if invoked accidentally.
Tassilo Horn
Christophe Troestler
Dirk-Jan C. Binnema
Nacho Barrientos
Thierry Volpiatto
DiGitHubCap
Salman Mohammadi
Alex Bennée
Yuri D'Elia
Jeff Filipovits
Jerry Snitselaar
Jonas Bernoulli
Giuseppe Fierro
Thierry Volpiatto
Zack Newman
Kevin J. Foley
Pierre Neidhardt
Junyeong Jeong
Alex Branham
Marcelo Henrique Cerri
Mekeor Melire
galaunay
Vladimir Sedach
Arne Köhn
Titus von der Malsburg
Sébastien Le Callonnec
Jun Hao
Antoine Levitt
Ævar Arnfjörð Bjarmason
Clément Pit--Claudel