[Top][All Lists]

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

Re: Interactive guide for new users

From: John Yates
Subject: Re: Interactive guide for new users
Date: Sun, 13 Sep 2020 12:38:14 -0400

On Sun, Sep 13, 2020 at 10:05 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > To my knowledge, if we want to come close to what those other editors
> > show, our current best bet is icomplete-vertical (or something similar
> > to it) PLUS a packages that moves the minibuffer to either the center or
> > the top of the frame (or makes it seem live the minibuffer has been
> > moved, of course).
> Those have an annoying misfeature of causing jumps in the window above
> the minibuffer.

Over the decades, as I have moved from a 24 line VT-100 to 32" 4K
/ 3840x2160 pixwl monitor with more than 80 lines of text, one of
the least pleasant changes in using emacs as has been the distance
my eyestravel to reach the minibuffer.

When a buffer contains fewer lines than its window the text is
vertically justified against the top of the window.  Thus my eyes
regularly flick from screen top to bottom and back.  Furthermore,
where previously, on screens with fewer lines, the minibuffer
remained within my field of view, today that is no longer the

IIUC, the misfeature to which Eli refers is a desire to preserve
visibility of a window's top line in the face of window resizing.
That is surely not unexpected behavior.  My guess is this model
springs from a desire to keep as much relevant context on screen
as possible.

An alternative UI model would be to think of growing a frame top
minibuffer as dropping down a shade over the existing window(s).
This dropping down would not trigger resizing.  Instead it would
obscure as much of the visible window(s) as necessary (at least
until the shade hits a window mode line or lower border).


reply via email to

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