bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#43572: Feature request: make it possible to choose whether the first


From: Stefan Monnier
Subject: bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones
Date: Wed, 23 Sep 2020 14:33:13 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

> One case in which this behavior is not desirable is when completion
> candidates are displayed with an overlay at the end of the buffer.
> When this overlay is taller than max-mini-window-height, the prompt and the
> user input so far disappear.  A simple example: M-: (setq
> max-mini-window-height 1), M-x icomplete-mode, M-x a.

You should update your recipe, because Eli's patch takes care of this
case already.

I'm not completely sure which case(s) you're thinking of now that Eli's
patch handles the most common case we've seen so far.  But maybe the
problem shows up when we have a minibuffer content that spans 2 lines,
in which case the redisplay will choose to show the last line
(assuming point is in the second line) plus icomplete's overlay rather
whereas you presumably would want to see both lines from the minibuffer
(and hence one line less from icomplete's overlay)?

So a recipe could look something like:

    src/emacs -Q --eval '(setq max-mini-window-height 2)' -f icomplete-mode
    C-x C-f 
lisp/progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../progmodes/../

where we see the whole of icomplete's overlay rather than seeing the
whole of the minibuffer's actual content.

In general both are perfectly valid choices and which one is best
depends on what is the intention behind the particular overlay and its
relation to the minibuffer's content, so indeed the redisplay would need
additional information in order to decide which behavior to choose.

> The attached patch makes it possible to (selectively) choose to display the
> _first_ lines of the minibuffer instead of its _last_ lines (which is and
> remains the default behavior).

Currently, the redisplay code focuses on making sure point is displayed.
In the resize_mini_widow code we try to accommodate some extra desires,
mostly in the form of giving more importance either to what's before point
or what's after it.

> The attached patch does not change the behavior of Emacs in any way,
> unless the feature it introduces is used.

I see the following potential problem with it: icomplete will likely
want to set it globally, but that means it will also affect uses of the
mini window where icomplete is not used.  Also, potential other users
may encounter similar difficulties.

I don't have a patch to suggest, but I think ideally, I'd want clients
like icomplete to tell the redisplay either something like "please
display as much as possible of *this* chunk of text" or maybe "feel free
not to display all of this overlay, it's not super important".

[ Note: "please display as much as possible of *this* chunk of text" is
  what I'd want to do in diff-mode when I move between chunks or in
  smerge-mode when I get to a new conflict, so maybe such a thing would
  make sense not just in the minibuffer.  ]


        Stefan






reply via email to

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