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 16:00:55 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>>    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.
>>
>
> The problem is that such a recipe would only work with a not-too-wide Emacs
> frame and a not-too-small default font.  For example, on my computer, it
> does not demonstrate the problem.

Really?  Despite the `-Q`?  Is it using a proportional font?
How many columns wide is the frame?
Oh, wait, is it because you're running that Emacs session in a tty
rather than in a GUI?

>>> 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.
> No, if you look at the patch its value is reset to nil whenever the
> minibuffer is entered.

That still leaves the non-minibuffer uses of the mini window (i.e. the
echo area).

And of course, that will also result in the use of an incorrect value
when you exit a *nested* minibuffer (unless both minibuffers were using
the same value).

>> 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".
>
> Yes, that's the point.  The patch I proposed tells redisplay "please display
> as much as possible of the text between BOB and point", when the current
> behavior tells redisplay "please display as much as possible of the text
> between point and EOB".  Something more fine-grained would of course be
> possible, but I don't think it is a good idea to implement a feature when
> there is no clear need for it.

I think what I was getting at is that this "request" should come from
the minibuffer's text rather than from a variable.


        Stefan






reply via email to

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