Re: Interactive guide for new users

[John Yates]

On Tue, Sep 15, 2020 at 3:01 AM Göktuğ Kayaalp <self@gkayaalp.com> wrote:

> 1) How does this interact with a scenario where user goes back and forth
> between editing the minibuffer vs. some displayed buffer?

I am aware that the current behavior supports this possible style
of interaction.  I cannot remember having ever used it myself.
Based on that experience my attitude is that such interactions
are rare enough that I am willing to disadvantage them a bit to
improve the more common cases.

To restore the ability to interact as you have described I
suggest a key binding to re-layout the all windows, including
the expanded minibuffer.

Would that not allow you to carry out your back and forth
interactions just as you would do today?

> 2) One might be looking at their notes while editing the minibuffer.
> E.g. imagine reading some docs and M-xing some commands from it, or
> naming an Org link, etc.

I am not sure I follow.

While one is reading the doc and M-xing commands, the minibuffer
is likely to be in its minimal, collapsed state, just as it would
be today.  Even if, while executing some M-x command, the
minibuffer were to grow to overlap some portion of the visible
window(s) I contend that, most likely, the user would complete
that interaction, thereby causing the minibuffer to revert to its
collapsed state, prior to the user needing to return to his/her
source document.

> 3) Would it be possible to revert this back to the current behaviour
> with a user option?

Of course.  That is the emacs way.  And, were such minibuffer
behavior ever to become available, I cannot imagine it being
shipped as the default.  It would be opt-in.

> 4) How is this better than how other editors do their ‘command
> palettes’? Isn’t it better to just pop up a centered frame and do
> completions there?   With the added benefit of being able to move the
> thing around and focus back to the buffer.

If you go back to when I first joined the thread you will see
that I am especially interested in optimizing emacs on very
large, hi res screens.  Popping up a dialog box in the middle of
such a screen is nearly as bad as expanding the minibuffer up
from the bottom of the screen.

I find the prospect of needing to drag a dialog box around less
appealing than the single key binding to re-layout the windows
(as suggested above).  A key binding is definitely more consitent
with emacs' traditional solutions.

> 5) While a command palette at the bottom of the application is somewhat
> obscure, one up top is probably novel. Frankly I don’t like the idea
> of having a single empty line right in the line of my sight,
> constantly, taking up space right where my eyes go by default when
> reading stuff.

You must live in a world devoid of title bars nor menu bars.

/john