New mu4e-split-view setting: single-window

[Vladimir Sedach]

Hello,

If you like mu4e but wish it did not create/delete/resize/switch Emacs
windows so much, you are welcome to try out a new setting that I have
implemented for the mu4e-split-view variable: 'single-window

When mu4e-split-view is set to 'single-window, mu4e will not perform any
window manipulation, and tries to minimize buffer switching in the
window that you are in. I find that this makes mu4e much more usable if
you run it alongside other windows in a single Emacs frame (as opposed
to in its own Emacs frame).

One other thing 'single-window does is make the mu4e-main view into a
minibuffer prompt.

In the future I plan to extend single-window mode by adding more
capabilities to mu4e-view-mode via minibuffer displays, to enable more
email management tasks to be done without having to switch to the
*mu4e-headers* buffer.

Dirk-Jan C. Binnema has merged the code into master in the Github mu
repository last week: https://github.com/djcb/mu

To try out the mode, install mu4e from the git repository and
(setq mu4e-split-view 'single-window)

If you are curious about how I use mu4e, my Emacs setup can be
viewed at: https://github.com/vsedach/emacs.d/blob/master/init.el#L439

Please let me know if you have any questions.

Happy hacking,
Vladimir

[Eduardo Mercovich]

Hi Vladimir.

> If you like mu4e but wish it did not create/delete/resize/switch
> Emacs
> windows so much, you are welcome to try out a new setting that I
> have
> implemented for the mu4e-split-view variable: 'single-window

> [...]

> If you are curious about how I use mu4e, my Emacs setup can be
> viewed at:
> https://github.com/vsedach/emacs.d/blob/master/init.el#L439

I found the idea interesting, but just can't really grok how it
changes mu4e look or behavior...

Do you have some screenshots, or videos, to share? (please don't
do them if you don't, it's just that since it changes mu4e as we
know it I am just curious).

Anyway, thanks a lot for adding your work to mu4e. :D

Best...

--
Eduardo Mercovich

Donde se cruzan tus talentos
con las necesidades del mundo,
ahí está tu vocación.
(Anónimo)

[Vladimir Sedach]

> I found the idea interesting, but just can't really grok how it
> changes mu4e look or behavior...

The mu4e look does not change - the main effect of the new setting is to
prevent a new window from being created for the *mu4e-headers* buffer
when the buffer is buried and some email action takes place (there were
about 5-6 other situations that also triggered window creation/deletion
and gratuitous buffer changes).

Since the focus of the setting is on not doing anything whenever
possible, I cannot think of a video demonstration that would show
anything interesting.

Happy hacking,
Vladimir

[Joost Kremers]

On Thu, Jun 08 2017, Vladimir Sedach wrote:
>> I found the idea interesting, but just can't really grok how it
>> changes mu4e look or behavior...

@Eduardo, it's a simple one-setting change, so why not try it out?

> The mu4e look does not change - the main effect of the new
> setting is to
> prevent a new window from being created for the *mu4e-headers*
> buffer
> when the buffer is buried and some email action takes place
> (there were
> about 5-6 other situations that also triggered window
> creation/deletion
> and gratuitous buffer changes).

Are these things a normal user would notice? Because when I just
tried it out, executing a search does provide a header buffer. But
it wouldn't make sense otherwise, of course.

One thing that doesn't work in my setup is what happens when I run
`mu4e~headers-quit-buffer': it quits mu4e altogether. with
mu4e-split-view set to `horizontal', it just returns to the main
view. The point is that I run OfflineIMAP from within Emacs, and
I've advised `mu4e-quit' to also kill OfflineIMAP.

I've also defined a function `mu4e-lower', which hides the mu4e
main view buffer but otherwise keeps it running, so mail still
gets fetched and indexed. The way `single-window' is implemented
now, leaving a headers buffer kills OfflineIMAP (which doesn't
have to be your concern, of course ;-) ) but IIUC it also disables
mu4e's update timer. Is that indeed the behaviour your going for?
If so, would it perhaps be a good idea to make that be
configurable?

On a more general, unrelated, note: how do people do this anyway?
I've had my setup for so long I forgot that it's not mu4e's
default behaviour...

Another unrelated question: why does mu4e~headers-quit-buffer have
a tilde, when it's an interactive function? :-)

Another thing (back to the new single-view option): Right now,
invoking mu4e gives you the minibuffer prompt, but if you select
e.g., 'Update email & database' or `;' to switch contexts, you end
up back in the (non-mu4e) buffer where you started. It would be
nice if instead the menu that's presented in the minibuffer would
still be active. One way to implement this is to do something
similar to what the hydra package does, which IIUC amounts to
creating a dedicated buffer for the menu and using
`set-transient-map' to set a temporary overriding key map.

HTH


--
Joost Kremers
Life has its moments

[Eduardo Mercovich]

Hi Joost.

>>> I found the idea interesting, but just can't really grok how
>>> it
>>> changes mu4e look or behavior...
>
> @Eduardo, it's a simple one-setting change, so why not try it
> out?

[...]

Because it means recompiling mu4e with the latest version.
This is something that many people in this wonderful list find
simple and fast, but that's not how I feel it (yet). ;)

The idea that something could go wrong and I'll have to
troubleshoot it to make my email work again (even more so on these
days, in the middle of a working delivery spree) makes me tremble.
But I'll probably try it in a month or so...

Best.

[Eduardo Mercovich]

Hi Vladimir.

> [...] the main effect of the new setting is to prevent a new
> window from being created for the *mu4e-headers* buffer [...]

> Since the focus of the setting is on not doing anything whenever
> possible, I cannot think of a video demonstration that would
> show anything interesting.

I can imagine a few different ways, like reusing 1 frame only for
everything (menu, headers, reading and writing) or combinations of
those, but i get the idea.
I'll try it ASA I got some time.

Anyway, thanks for adding to mu4e. :D

[Vladimir Sedach]

> Are these things a normal user would notice? Because when I just
> tried it out, executing a search does provide a header buffer. But
> it wouldn't make sense otherwise, of course.

When I have 3 or more Emacs windows open, split both vertically and
horizontally, the default mu4e split-view behavior is definitely
noticeable. The headers buffer would pop up in random and inconvenient
places (at the top of another column, in the bottom, ...) if it was
previously buried. Sometimes one of the whole-column windows would get
killed and throw off the whole layout.

I use Emacs as my window manager (EXWM) and usually have a lot of Emacs
windows open when reading and replying to email, to look things up in
dired, PDF viewer, web browser, code, etc.

> One thing that doesn't work in my setup is what happens when I run
> `mu4e~headers-quit-buffer': it quits mu4e altogether. with
> mu4e-split-view set to `horizontal', it just returns to the main
> view. The point is that I run OfflineIMAP from within Emacs, and
> I've advised `mu4e-quit' to also kill OfflineIMAP.

You are right, it was my mistake to make mu4e~headers-quit-buffer quit
mu4e. The obvious thing for it to do is just to kill the current buffer.

> On a more general, unrelated, note: how do people do this anyway?
> I've had my setup for so long I forgot that it's not mu4e's
> default behaviour...

Right now I have 9 email accounts across various providers and work
offline a lot, and in general disable all notifications. My setup is to
run offlineimap manually from eshell, mu4e-update-index is done by the
`g' key, and both mail queueing and sending is done by smtpmail.el -
sending is done asynchronously by another emacs process in batch mode
run from eshell.

> Another thing (back to the new single-view option): Right now,
> invoking mu4e gives you the minibuffer prompt, but if you select
> e.g., 'Update email & database' or `;' to switch contexts, you end
> up back in the (non-mu4e) buffer where you started. It would be
> nice if instead the menu that's presented in the minibuffer would
> still be active. One way to implement this is to do something
> similar to what the hydra package does, which IIUC amounts to
> creating a dedicated buffer for the menu and using
> `set-transient-map' to set a temporary overriding key map.

That is a very good suggestion. I made a change to make ; loop back to
the minibuffer main menu.

I tried it out also for Update, but that clashed with GnuPG pinentry.
Even without pinentry, it was not obvious when to display the minibuffer
main menu: right away, while offlineimap/mu processes were still running
(but then you don't have the latest mail), or make a
mu4e-update-post-hook (but offlineimap takes so long I would be doing
something in another buffer, and having anything pop up is exactly what
single-window is made to avoid).

The changes can be seen in this Github pull request:
https://github.com/djcb/mu/pull/1095/files

Please let me know how well that works or if you think other things need
fixing.

Thank you,
Vladimir

[Vladimir Sedach]

> Because it means recompiling mu4e with the latest version.
> This is something that many people in this wonderful list find
> simple and fast, but that's not how I feel it (yet). ;)

Actually the problem is with stale .elc files. If you set the variable
load-prefer-newer to t, Emacs will load whichever of .el or .elc file is
newer when you load or require a file without an explicit file
extension. I find this very useful and have it on all the time.

I also avoided the recompiling problem entirely by never byte-compiling
any of the mu4e files.

Happy hacking,
Vladimir

[Eduardo Mercovich]

Hi Vladimir.

[...]

>> Because it means recompiling mu4e with the latest version.
>> This is something that many people in this wonderful list find
>> simple and fast, but that's not how I feel it (yet). ;)

> Actually the problem is with stale .elc files. If you set the
> variable

> load-prefer-newer to t, [...]

> I also avoided the recompiling problem entirely by never
> byte-compiling
> any of the mu4e files.

Maybe what I do is not compiling (which tell you how much I do
understand about this).
I mean configure, make, install...

Once that broke my installation of mu4e and I was 2 days searching
until I could find what I did wrong. Of course it was my mistake
(a path in my Debian slightly different from the expected), but
still, I had to endure that troubleshooting. If experience is what
you get when you didn't get what you wanted, I got a lot of
experience. ;)

Is that compiling?