handling of windows

[Alan Schmitt]

Hello,

I often have trouble with mu4e changing my emacs window layout. I know
of solutions to undo such changes or to save layouts, but it feels that
with a few changes mu4e would become much more window friendly.

First, it would be great if 'R' (reply to message) would take control of
the whole window (including the header window). (As I write this, and
describe other changes below, I realize it's quite a tricky problem. On
the one hand, one would like to have a header's window when viewing the
message to have some context. On the other hand, this header's window
should be strongly attached to the viewing pane such that it may
disappear when a reply is composed.)

Second, it would be great to have several mu4e-headers buffers, one for
each search. It seems that doing a search or a jump results in the old
buffer being stolen, and going away, messing the layout in other frames
(which may not be visible). Trying to jump to an existing (visible)
buffer should result in a message saying that the buffer is visible in
another window.

Third, when burying a buffer, if the result would show a header buffer
that is visible somewhere, then display another buffer. The goal, once
again, is to avoid stealing a window from another frame.

I don't know if these things are difficult to implement. They would just
greatly my mu4e experience (which is already amazing, by the way).

Thanks,

Alan

[Dirk-Jan C. Binnema]

Hi Alan,

On Wed, Mar 20 2013, Alan Schmitt wrote:

> I often have trouble with mu4e changing my emacs window layout. I know
> of solutions to undo such changes or to save layouts, but it feels
> that with a few changes mu4e would become much more window friendly.
>
> First, it would be great if 'R' (reply to message) would take control of
> the whole window (including the header window). (As I write this, and
> describe other changes below, I realize it's quite a tricky problem. On
> the one hand, one would like to have a header's window when viewing the
> message to have some context. On the other hand, this header's window
> should be strongly attached to the viewing pane such that it may
> disappear when a reply is composed.)
>
> Second, it would be great to have several mu4e-headers buffers, one for
> each search. It seems that doing a search or a jump results in the old
> buffer being stolen, and going away, messing the layout in other frames
> (which may not be visible). Trying to jump to an existing (visible)
> buffer should result in a message saying that the buffer is visible in
> another window.
>
> Third, when burying a buffer, if the result would show a header buffer
> that is visible somewhere, then display another buffer. The goal, once
> again, is to avoid stealing a window from another frame.

It is a bit of a balancing act -- e.g. I started with having multiple
header buffers, but it got confusing quickly, both in the UI and in the
code. So, I switched to the current 'mutt' model, which has its
limitation, but is at least somewhat understandable.

Emacs window management is another fun-topic. I think it usually works
these days -- but it's certainly not perfect.

Best wishes,
Dirk.

--
Dirk-Jan C. Binnema Helsinki, Finland
e:dj...@djcbsoftware.nl w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C

[Oscar Carlsson]

Alan Schmitt writes:

> I often have trouble with mu4e changing my emacs window layout. I know
> of solutions to undo such changes or to save layouts, but it feels that
> with a few changes mu4e would become much more window friendly.

I'm using elscreen to manage my window configurations, keeping my mu4e
at screen 0 and other window configurations at others screens. I've
disabled the tab bar and have bound C-c t to go between screens. It's
the best way to handle windows I've found this far.


Oscar

[Alan Schmitt]

Hi Dirk,

Dirk-Jan C. Binnema writes:

> It is a bit of a balancing act -- e.g. I started with having multiple
> header buffers, but it got confusing quickly, both in the UI and in the
> code. So, I switched to the current 'mutt' model, which has its
> limitation, but is at least somewhat understandable.

I understand. Would it be possible, keeping the current model, to avoid
changing the layout of other frames? (I'm not 100% sure of when it
happens, I can try to reproduce it if it's helpful.)

> Emacs window management is another fun-topic. I think it usually works
> these days -- but it's certainly not perfect.

Yes, it's the thing that frustrates me the most (and it's really not a
deal killer, I have to say).

Thanks,

Alan

[Alan Schmitt]

Thank you for the suggestion, I'm giving it a try.

I have a workflow question for you: if you're in the middle of writing
or reading an email, and want to have a look at another one (while
keeping what you're doing visible), how do you do it? Until now, I was
using some code that would open a new frame with a mu4e search prompt,
but this frame approach would not work with elscreen.

Thanks,

Alan

[Dirk-Jan C. Binnema]

Hi Alan,

On Fri, Mar 22 2013, Alan Schmitt wrote:

> Hi Dirk,
>
> Dirk-Jan C. Binnema writes:
>
>> It is a bit of a balancing act -- e.g. I started with having multiple
>> header buffers, but it got confusing quickly, both in the UI and in the
>> code. So, I switched to the current 'mutt' model, which has its
>> limitation, but is at least somewhat understandable.
>
> I understand. Would it be possible, keeping the current model, to avoid
> changing the layout of other frames? (I'm not 100% sure of when it
> happens, I can try to reproduce it if it's helpful.)

Sure, if you have some steps, I can take a look. It might simply be a
bug.

>> Emacs window management is another fun-topic. I think it usually works
>> these days -- but it's certainly not perfect.
>
> Yes, it's the thing that frustrates me the most (and it's really not a
> deal killer, I have to say).

That's good to know :) But I'm always open for suggestions, esp. if
there are simple ways to improve the user-experience.

[Oscar Carlsson]

I'd probably type M-§ (bound to delete-window, normally C-x 0) in my
message buffer window, find the relevant mail, and then switch to my
message buffer again. Not perfect.


Oscar

[Joost Kremers]

On Fri, Mar 22 2013, Dirk-Jan C. Binnema <dj...@djcbsoftware.nl> wrote:
> That's good to know :) But I'm always open for suggestions, esp. if
> there are simple ways to improve the user-experience.

One thing I'd really appreciate is a way to get rid of the headers
window when replying to a message. When I write a longer reply to a
message, the visible headers window is ofter superfluous and I'd like to
get rid of it. Right now, I usually do C-x 1, but that only hides the
headers window, it doesn't quit the headers buffer properly.

Other than that, I'm quite happy with the way things are. I considered
whether I'd want mu4e to delete all other windows and take over the
entire frame. That would make it rather easy to restore the window
layout after quitting mu4e, but I think I it's better the way it is.
It's not uncommon for me to want to run mu4e in one window and have
something else displayed in another window.

Though perhaps you could consider whether this could be a
user-customisable option: either mu4e takes over the entire frame, which
entails that the window configuration is restored after leaving mu4e, or
mu4e just usurps the active window, which entails that the buffer in
that window is restored when leaving mu4e, but not the entire window
configuration.


--
Joost Kremers
Life has its moments

[Alan Schmitt]

Hi Dirk,

Dirk-Jan C. Binnema writes:

>> I understand. Would it be possible, keeping the current model, to avoid
>> changing the layout of other frames? (I'm not 100% sure of when it
>> happens, I can try to reproduce it if it's helpful.)
>
> Sure, if you have some steps, I can take a look. It might simply be a
> bug.

Of course I'm unable to reproduce it right now :(

I'll keep my eyes open and will update this thread if I can find a
reproducible example.

Thanks,

Alan

[Alan Schmitt]

I've finally been able to reproduce my problem.

What I want to do: I am reading a message, and I want to go read another
one in parallel (to compare them).

What I do: start with a vertically split screen. Start mu4e in one
window, find the message. I then "C-x 0" the headers pane just to have
the message in this window. I then switch to the other window, and do a
"M-x mu4e-headers-search". This is where the problem happens: the result
takes the whole frame, removing my carefully crafted window.

Does this qualify as a bug?

Thanks,

Alan

[Dirk-Jan C. Binnema]

Hi Alan,

Well, currently mu4e tries hard /not/ to allow you to have multiple view
windows open at the same time. Since view windows need header windows to
do things like deletion, go-to-next etc., you'd also need multiple
header windows, which becomes confusing quickly.

But, I'd be happy to experiment a bit with this...

[Alan Schmitt]

Hi Dirk,

Dirk-Jan C. Binnema writes:

> Well, currently mu4e tries hard /not/ to allow you to have multiple view
> windows open at the same time. Since view windows need header windows to
> do things like deletion, go-to-next etc., you'd also need multiple
> header windows, which becomes confusing quickly.
>
> But, I'd be happy to experiment a bit with this...

I'd gladly beta test this, as viewing several messages at the same time
is something I need from time to time.

Thanks,

Alan