emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interactive guide for new users


From: Göktuğ Kayaalp
Subject: Re: Interactive guide for new users
Date: Tue, 15 Sep 2020 10:00:43 +0300
User-agent: mu4e 1.2.0; emacs 28.0.50

On 2020-09-15 04:42 +03, John Yates <john@yates-sheets.org> wrote:
>> That'd be a misfeature, no?  The text you were working on or reading
>> will disappear from view.  To say nothing about the fact this would
>> mean a major surgery of the display code.
> I do not feel so.  In most other UIs to which I have been exposed,
> when a dialog box pops up, there is usually no attempt to preserve
> visibility of any particular portion of the underlying application.
> Sometimes the dialog box can be dragged but my impression is that
> an increasing number of frameworks are foregoing that nicity.  My
> guess is that this is because, with properly designed interactions,
> it is exceedingly rare to need to refer back to the underlying
> application in order to complete the dialog box interaction.

Emacs supports far richer interactions than usual desktop applications
(some examples in the questions below).  It’s more than just ‘referring
back’ in Emacs’ case.

> Minibuffer in its minimal, collapsed, single line state:
[... snip ...]
> Minibuffer grows by one line, "shading" the first mode line:
[... snip ...]
> Minibuffer grows to five lines, "shading" 3 lines of window 1's contents:
[... snip ...]
> It is this minibuffer growing from the top of the frame downward and
> obscuring whatever it encounters that I describe as a "drop down shade".
>
> I understand that this is a new display behavior.  That said, is it
> not simpler and entirely independent of how resizing the minibuffer
> works today?

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

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.

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

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.

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.

--
İ. Göktuğ Kayaalp / @cadadr / <https://www.gkayaalp.com/>
pgp:   024C 30DD 597D 142B 49AC 40EB 465C D949 B101 2427



reply via email to

[Prev in Thread] Current Thread [Next in Thread]