Re: Interactive guide for new users

[John Yates <john@yates-sheets.org>]

On Mon, Sep 14, 2020 at 11:28 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: John Yates <john@yates-sheets.org>
> >
> > * On growing the minibuffer, no attempt to keep point or windows visible
>
> 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.

> >  (i.e. a variable-height drop-down shade)
>
> Can you elaborate about this (and its relevance to growing the
> mini-window)?  I don't think I see the relation.

Forgive me if I inaccurately conflate the minibuffer and the echo
area.  Let me try some pictures.


Minibuffer in its minimal, collapsed, single line state:

+=========================== Top of Frame ==========================
| Minibuffer line 1
+------------------------ Top Edge Window 1 ------------------------
| Window 1 Mode line
+-------------------------------------------------------------------
| a
| b
| c
| Window 1 contents
| x
| y
| z
+----------------------- Top Edge Window 2 ------------------------
| Window 2 Mode line
+-------------------------------------------------------------------
| p
| q
| r
| Window 1 contents
| u
| v
| w
+-======================== Bottom of Frame =========================



Minibuffer grows by one line, "shading" the first mode line:

+=========================== Top of Frame ==========================
| Minibuffer line 1
| Minibuffer line 2
+-------------------------------------------------------------------
| a
| b
| c
| Window 1 contents
| x
| y
| z
+------------------------ Top Edge Window 2 ------------------------
| Window 2 Mode line
+-------------------------------------------------------------------
| p
| q
| r
| Window 1 contents
| u
| v
| w
+========================= Bottom of Frame =========================



Minibuffer grows to five lines, "shading" 3 lines of window 1's contents:

+=========================== Top of Frame ==========================
| Minibuffer line 1
| Minibuffer line 2
| Minibuffer line 3
| Minibuffer line 4
| Minibuffer line 5
+-------------------------------------------------------------------
| Window 1 contents
| x
| y
| z
+------------------------ Top Edge Window 2 ------------------------
| Window 2 Mode line
+-------------------------------------------------------------------
| p
| q
| r
| Window 1 contents
| u
| v
| w
+========================= Bottom of Frame =========================


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?

/john