GNU bug report logs -
#43572
Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones
Previous Next
Reported by: Gregory Heytings <ghe <at> sdf.org>
Date: Tue, 22 Sep 2020 20:58:02 UTC
Severity: wishlist
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43572 in the body.
You can then email your comments to 43572 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Tue, 22 Sep 2020 20:58:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Gregory Heytings <ghe <at> sdf.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 22 Sep 2020 20:58:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
In Emacs 27.1, the mini-window displays the last lines of the minibuffer.
This is, in general, the desired behavior, but in some cases it is not.
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.
Because of this behavior, and because it is counter-intuitive / not
user-friendly when the prompt and user input so far disappear, those who
create programs that display such completion candidates have been
struggling to create overlays in such a way that they are (together with
the prompt and the user input so far) not taller than
max-mini-window-height. Doing this is, in general, far from trivial.
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). This means that displaying completion
candidates becomes a trivial task: it suffices to create an overlay with
completion candidates, without worrying at all about its size (or about
the size of the prompt and user input), and as many of these candidates as
possible will automatically be displayed.
For example, implementing vertical icomplete only requires:
(setq icomplete-separator "\n")
(add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t)))
This feature request follows the discussion in bug#43519. The change
proposed there by Eli Zaretskii improves the behavior w.r.t. Emacs 27.1,
but it is still suboptimal to display completion candidates in a
user-friendly way. For example:
Find file: <user input>|
<completion candidates>
(where | represents the cursor) will become:
<user input>|
<completion candidates>
when the user input becomes larger than a line. That is, the "Find file:"
prompt and the user input on the first line will disappear.
The attached patch does not change the behavior of Emacs in any way,
unless the feature it introduces is used.
[start-display-at-beginning-of-minibuffer.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 15:18:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Sep 2020 20:57:13 +0000
> From: Gregory Heytings via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> In Emacs 27.1, the mini-window displays the last lines of the minibuffer.
>
> This is, in general, the desired behavior, but in some cases it is not.
>
> 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.
Actually, on the current master this example does show the "M-x a"
part.
> This feature request follows the discussion in bug#43519. The change
> proposed there by Eli Zaretskii improves the behavior w.r.t. Emacs 27.1,
> but it is still suboptimal to display completion candidates in a
> user-friendly way. For example:
>
> Find file: <user input>|
> <completion candidates>
>
> (where | represents the cursor) will become:
>
> <user input>|
> <completion candidates>
>
> when the user input becomes larger than a line. That is, the "Find file:"
> prompt and the user input on the first line will disappear.
I suggest to show a recipe for this, because the few I tried failed to
produce the described effect (with the current master). Maybe I'm
missing something.
> 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). This means that displaying completion
> candidates becomes a trivial task: it suffices to create an overlay with
> completion candidates, without worrying at all about its size (or about
> the size of the prompt and user input), and as many of these candidates as
> possible will automatically be displayed.
>
> For example, implementing vertical icomplete only requires:
>
> (setq icomplete-separator "\n")
> (add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t)))
I have a couple of comments regarding the proposed change:
. How will Lisp programs decide when to set this flag and when not to
set it? What would be the criteria? If you are saying that any
Lisp program that reads from the minibuffer will want that, then
(assuming that others agree), it would be better to do this
automatically in the display code.
. Binding the variable inside the minibuffer-setup-hook will affect
all the subsequent calls to resize_mini_window, until the next call
to read-from-minibuffer resets it, which may not be what the Lisp
program wants, and could have unintended consequences.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 18:34:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 18:48:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Wed, 23 Sep 2020 14:33:13 -0400
> Cc: 43572 <at> debbugs.gnu.org
>
> 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. ]
This could be a useful new feature, but we still need to decide what
should the display engine do when the chunk of text marked with this
new indication (some text property, probably?) cannot all of it be
displayed. Should it then display only its first part, only its last
part, something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 19:16:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> In Emacs 27.1, the mini-window displays the last lines of the
>> minibuffer.
>>
>> This is, in general, the desired behavior, but in some cases it is not.
>>
>> 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.
>
> Actually, on the current master this example does show the "M-x a" part.
>
Yes, as I explain just below. It's an improvement that improves most, but
not all, cases.
>> This feature request follows the discussion in bug#43519. The change
>> proposed there by Eli Zaretskii improves the behavior w.r.t. Emacs
>> 27.1, but it is still suboptimal to display completion candidates in a
>> user-friendly way. For example:
>>
>> Find file: <user input>|
>> <completion candidates>
>>
>> (where | represents the cursor) will become:
>>
>> <user input>|
>> <completion candidates>
>>
>> when the user input becomes larger than a line. That is, the "Find
>> file:" prompt and the user input on the first line will disappear.
>
> I suggest to show a recipe for this, because the few I tried failed to
> produce the described effect (with the current master). Maybe I'm
> missing something.
>
I just tested this again with current master, and actually the result is
slighly worse than what I though, when the prompt and user input becomes
larger than a line you don't see:
<user input>|
<completion candidates>
but:
|<completion candidates>
(IOW the characters at the beginning of the Nth line, with N > 1,
disappear.)
Again it's difficult to give a simple recipe, because it depends on the
width of your Emacs frame and of the size of the font used in the
mini-window. The simplest recipe I can think of is:
1. create a "long enough" directory name, with say ten subdirectories
2. emacs -Q
3. make the frame width "small enough"
4. M-: (setq max-mini-window-height 5)
5. M-x icomplete-mode
6. M-: (setq icomplete-separator "\n")
7. C-x C-f and enter the "long enough" directory name
What you will see at this point is:
|{<completion candidate 1>
<completion candidate 2>
...
<completion candidate 5>
>
> How will Lisp programs decide when to set this flag and when not to set
> it? What would be the criteria?
>
The criteria is simply: should the prompt and user input be displayed?
IOW, is what Stefan called the "real content" (prompt and user input so
far) more important that the overlay (which displays completion candidates
but is merely an unnecessary help for the user)?
Programs such as icomplete and ido, for example, would most likely want to
set this flag.
(A more precise way to formulate that criteria would be: should the prompt
and user input be displayed, unless it is impossible to display them?)
>
> If you are saying that any Lisp program that reads from the minibuffer
> will want that, then (assuming that others agree), it would be better to
> do this automatically in the display code.
>
This is not what I'm saying, and I would not dare to make such a general
judgment. I only claim that it is better to make this possible.
There is at least one case where I think it is better not to do this
automatically. As Stefan indicated in bug#43519, with M-:, when you input
data, the current behavior is to always have point on the last line of the
minibuffer. Doing this automatically (that is, unconditionally) would
have the consequence that when point reaches the last line of the
minibuffer (that is, the max-mini-window-height's line), the mini-buffer
would be recentered, and the topmost lines would be hidden. This happens
because the default value of scroll-conservatively is 0; when it is set to
101 it does not happen anymore.
This is just one case, there are possibly many other cases. But IMO, the
mini-buffer is so central to Emacs, and the current behavior is so old
(twenty years), that I believe changing it requires a lot of care. This
could be done in small steps:
1. first with this patch (or if you want with the opposite patch: a
variable start-display-at-end-of-minibuffer reset to t whenever the
mini-buffer is entered), which would make it possible to everyone to try
to set that variable to its non-default value to see if undesirable
behaviors arise,
2. then by changing the default value to its opposite, say in Emacs 29, if
it became clear enough that the new behavior does not give rise to any
undesiable consequences,
3. and finally, in Emacs 3X, by removing that variable.
>
> Binding the variable inside the minibuffer-setup-hook will affect all
> the subsequent calls to resize_mini_window, until the next call to
> read-from-minibuffer resets it, which may not be what the Lisp program
> wants, and could have unintended consequences.
>
I can't think of such unintended consequences. In the use case of
displaying completion candidates, this (the fact that it affects all
successive calls to resize_mini_window) is indeed what is wanted.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 19:38:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Sep 2020 19:15:40 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: 43572 <at> debbugs.gnu.org
>
> I just tested this again with current master, and actually the result is
> slighly worse than what I though, when the prompt and user input becomes
> larger than a line you don't see:
>
> <user input>|
> <completion candidates>
>
> but:
>
> |<completion candidates>
>
> (IOW the characters at the beginning of the Nth line, with N > 1,
> disappear.)
>
> Again it's difficult to give a simple recipe, because it depends on the
> width of your Emacs frame and of the size of the font used in the
> mini-window. The simplest recipe I can think of is:
>
> 1. create a "long enough" directory name, with say ten subdirectories
> 2. emacs -Q
> 3. make the frame width "small enough"
> 4. M-: (setq max-mini-window-height 5)
> 5. M-x icomplete-mode
> 6. M-: (setq icomplete-separator "\n")
> 7. C-x C-f and enter the "long enough" directory name
>
> What you will see at this point is:
>
> |{<completion candidate 1>
> <completion candidate 2>
> ...
> <completion candidate 5>
Is this worse than before the change?
And given the policy of displaying the last visible part, what would
you expect in this case?
> > How will Lisp programs decide when to set this flag and when not to set
> > it? What would be the criteria?
>
> The criteria is simply: should the prompt and user input be displayed?
How do you decide that? Or let me ask it differently: when will a
program decide that it wants the current behavior of perhaps NOT
showing the prompt, if the mini-window is not large enough?
> (A more precise way to formulate that criteria would be: should the prompt
> and user input be displayed, unless it is impossible to display them?)
We are discussing the case when it's impossible to display both; the
case when it's possible is easy and is already handled.
> There is at least one case where I think it is better not to do this
> automatically. As Stefan indicated in bug#43519, with M-:, when you input
> data, the current behavior is to always have point on the last line of the
> minibuffer.
That case doesn't need any special handling in resize_mini_window,
because the display engine will always make sure point is visible. If
the window-start point determined by resize_mini_window doesn't allow
point to be visible, the display engine will find another
window-start, which would.
> Doing this automatically (that is, unconditionally) would
> have the consequence that when point reaches the last line of the
> minibuffer (that is, the max-mini-window-height's line), the mini-buffer
> would be recentered, and the topmost lines would be hidden.
What resize_mini_window does ensures that recentering doesn't happen.
That is why it sets w->start: it's an indication to the display engine
to obey that window-start position if point is visible with it.
So you are trying to solve a case that doesn't need to be solved.
> > Binding the variable inside the minibuffer-setup-hook will affect all
> > the subsequent calls to resize_mini_window, until the next call to
> > read-from-minibuffer resets it, which may not be what the Lisp program
> > wants, and could have unintended consequences.
>
> I can't think of such unintended consequences. In the use case of
> displaying completion candidates, this (the fact that it affects all
> successive calls to resize_mini_window) is indeed what is wanted.
Well, I _can_ think of such consequences. As I said,
resize_mini_window is called in many situations that don't involve
completion, so setting that variable to affect all of them is a bad
idea. We need something more fine-grained if we want to implement
such a feature.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 19:47:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> 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.
>
Indeed, but this recipe is what exists in Emacs 27.1 and what most people
can try immediately. The "problem" with Eli's patch is that it takes care
of 95% of the cases, and that the remaining 5% are more difficult to see,
yet are there.
>
> 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)?
>
Yes. See the recipe in my previous mail. If works with N lines, with N >
1.
>
> 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.
>
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.
>
> 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.
>
I agree with you, which is why I think that ATM the best thing to do is
just to make such a choice possible.
>
>> 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.
>
I don't think this is precise enough, but OTOH it's very hard to precisely
define what happens. Currently resize_mini_window() sets "start" to
max-mini-window-height lines before the end of the buffer (unless
resize-mini-windows is nil, in which case "start" is set to BOB). The
redisplay code takes that value; if point is not between start and EOB it
overrides it, otherwise it displays the buffer between start and EOB.
>
>> 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. And the example I gave with icomplete is:
(add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t)))
where icomplete-minibuffer-setup-hook is run during minibuffer setup if
(and only if) icomplete is active. So the behavior with M-: for example
would not be affected.
>
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 20:02:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 20:17:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>
> And given the policy of displaying the last visible part, what would you
> expect in this case?
>
I do not expect something else with the current policy, I suggest to add a
new policy with whom the first part of the minibuffer would be displayed
instead of its last part.
>>> How will Lisp programs decide when to set this flag and when not to
>>> set it? What would be the criteria?
>>
>> The criteria is simply: should the prompt and user input be displayed?
>
> How do you decide that?
>
I gave a simple and clear example of an implementation of vertical
icomplete, which demonstrates how this feature would be used:
(setq icomplete-separator "\n")
(add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t)))
Please try it (together with my patch), you'll see what I mean.
With the current behavior (with (setq icomplete-separator "\n")), whenever
the prompt and user input are larger than the width of Emacs' frame and
there are too many completion candidates, the prompt and user input
disappear, and when there are only a few completion candidates the prompt
and user input re-appear.
With this patch the prompt and user input are always visible, and as many
completion candidates as possible (given max-mini-window-height) are
displayed after them.
>
> Or let me ask it differently: when will a program decide that it wants
> the current behavior of perhaps NOT showing the prompt, if the
> mini-window is not large enough?
>
In the use case of completion candidates displayed after point with an
overlay at EOB, the answer is simple: never. If at some point it becomes
impossible to display the prompt, say because max-mini-window-height
equals 1 and the prompt and user input are larger than the width of the
Emacs frame, redisplay will hide the prompt, and that's fine. As you
said: "Displaying long stuff in a mini-window that is forced to be small
will always present some problems, no matter what we do."
>> Doing this automatically (that is, unconditionally) would have the
>> consequence that when point reaches the last line of the minibuffer
>> (that is, the max-mini-window-height's line), the mini-buffer would be
>> recentered, and the topmost lines would be hidden.
>
> What resize_mini_window does ensures that recentering doesn't happen.
> That is why it sets w->start: it's an indication to the display engine
> to obey that window-start position if point is visible with it.
>
> So you are trying to solve a case that doesn't need to be solved.
>
I'm not trying to solve any problem here. You said: "If you are saying
that any Lisp program that reads from the minibuffer will want that, then
(assuming that others agree), it would be better to do this automatically
in the display code." I answered this by saying: "This is not what I'm
saying, and I would not dare to make such a general judgment. I only
claim that it is better to make this possible. There is at least one case
where I think it is better not to do this automatically." And I explained
that case.
>>> Binding the variable inside the minibuffer-setup-hook will affect all
>>> the subsequent calls to resize_mini_window, until the next call to
>>> read-from-minibuffer resets it, which may not be what the Lisp program
>>> wants, and could have unintended consequences.
>>
>> I can't think of such unintended consequences. In the use case of
>> displaying completion candidates, this (the fact that it affects all
>> successive calls to resize_mini_window) is indeed what is wanted.
>
> Well, I _can_ think of such consequences. As I said, resize_mini_window
> is called in many situations that don't involve completion, so setting
> that variable to affect all of them is a bad idea. We need something
> more fine-grained if we want to implement such a feature.
>
It would be very helpful if you could clarify what the consequences you
think of are.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 22:48:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 43572 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> Really? Despite the `-Q`? Is it using a proportional font?
> Oh, wait, is it because you're running that Emacs session in a tty rather than in a GUI?
>
Yes, yes, no, no ;-)
>
> How many columns wide is the frame?
>
167, Sir! ;-)
>> 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).
>
Thank you very much for the pointers, indeed I completely forgot about
these cases. See the attached corrected patch, in which they are dealt
with. I believe start_display_at_beginning_of_minibuffer how has the
value it should have whenever resize_mini_window() is called.
>>> 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.
>
If this were possible, it would be even better indeed. An "importance"
text property, which would inform redisplay (?) of the relative importance
of the parts of the buffer. But implementing this is several orders of
magnitude harder than implementing my proposal.
[start-display-at-beginning-of-minibuffer.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 23:00:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>>> Binding the variable inside the minibuffer-setup-hook will affect all
>>> the subsequent calls to resize_mini_window, until the next call to
>>> read-from-minibuffer resets it, which may not be what the Lisp program
>>> wants, and could have unintended consequences.
>>
>> I can't think of such unintended consequences. In the use case of
>> displaying completion candidates, this (the fact that it affects all
>> successive calls to resize_mini_window) is indeed what is wanted.
>
> Well, I _can_ think of such consequences. As I said, resize_mini_window
> is called in many situations that don't involve completion, so setting
> that variable to affect all of them is a bad idea. We need something
> more fine-grained if we want to implement such a feature.
>
I believe I have dealt with these consequences (or at least with some of
them) in the update patch I just sent. Feel free to tell me if there are
other cases in which resize_mini_window() is called with a wrong value for
start_display_at_beginning_of_minibuffer. It is now saved by
read_minibuf(), and reset by read_minibuf() and read_minibuf_unwind().
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 23:19:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> This could be a useful new feature, but we still need to decide what
> should the display engine do when the chunk of text marked with this
> new indication (some text property, probably?) cannot all of it be
> displayed. Should it then display only its first part, only its last
> part, something else?
I think this can be controlled with the position of point (which
I guess should be presumed to be somewhere within the "important
chunk"). The idea would be to maximize the amount of chunk that's
displayed, but under the usual constraint that point is displayed.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 23:21:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> Really? Despite the `-Q`? Is it using a proportional font?
>> Oh, wait, is it because you're running that Emacs session in a tty rather than in a GUI?
> Yes, yes, no, no ;-)
>> How many columns wide is the frame?
> 167, Sir! ;-)
How? why?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Wed, 23 Sep 2020 23:27:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>>> Really? Despite the `-Q`? Is it using a proportional font?
>>> Oh, wait, is it because you're running that Emacs session in a tty rather than in a GUI?
>>
>> Yes, yes, no, no ;-)
>>
>>> How many columns wide is the frame?
>>
>> 167, Sir! ;-)
>
> How? why?
>
Simply because I asked my window manager to always maximize Emacs frames.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 02:08:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Simply because I asked my window manager to always maximize Emacs frames.
Aha!
Yet another loophole!
Thanks,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 07:46:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> Simply because I asked my window manager to always maximize Emacs
>> frames.
>
> Aha!
>
> Yet another loophole!
>
Hmm... Given the popularity (among a certain kind of users) of tiling
window managers and the popularity (among a much larger kind of users) of
using fullscreen apps, I don't think Emacs can expect to fully control the
size of its frame. But indeed I see what you mean, ideally emacs -Q
should give a frame of the same size everywhere. So it could perhaps make
sense to try to do something like:
(set-frame-width nil 80)
(set-frame-height nil 40)
(which works for me) at the end of the initialization process with "-q" or
"-Q".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 08:07:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 43572 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
To illustrate the need for this feature, I attach four screenshots taken
under the exact same conditions.
- "vanilla.png" is what a user would see without changing any default
(after pressing TAB to display the completion candidates): the prompt,
their input, and completion candidates in a *Completions* buffer above the
minibuffer
- "master-icomplete-vertical-after-tab.png" is what a user would see with
icomplete-mode activated and (setq icomplete-separator "\n") after having
completed the last directory name with a TAB: the prompt and their input
is completely hidden
- "master-icomplete-vertical-after-tab-tab.png" is what a user would see
after pressing TAB a second time; note the "ng/" before point, which was
hidden after pressing TAB for the first time and is now visible again
- "patched-icomplete-vertical.png" is what a user would see with the
proposed patch
[vanilla.png (image/png, attachment)]
[master-icomplete-vertical-after-tab.png (image/png, attachment)]
[master-icomplete-vertical-after-tab-tab.png (image/png, attachment)]
[patched-icomplete-vertical.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 14:21:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Cc: 43572 <at> debbugs.gnu.org
> Date: Wed, 23 Sep 2020 19:46:18 +0000
> From: Gregory Heytings via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> >> 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. And the example I gave with icomplete is:
>
> (add-hook 'icomplete-minibuffer-setup-hook (lambda () (setq start-display-at-beginning-of-minibuffer t)))
>
> where icomplete-minibuffer-setup-hook is run during minibuffer setup if
> (and only if) icomplete is active. So the behavior with M-: for example
> would not be affected.
There are more callers of resize_mini_widow than just those. It is
not safe to assume that this can be handled only inside read_minibuf.
So I agree with Stefan that the text inserted into the minibuffer
should itself indicate to the display engine that it wants to be
displayed starting at BOB. That way we don't have to worry about
inadvertently affecting other users of the mini-window.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 14:25:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Sep 2020 20:15:54 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: 43572 <at> debbugs.gnu.org
>
> >> I can't think of such unintended consequences. In the use case of
> >> displaying completion candidates, this (the fact that it affects all
> >> successive calls to resize_mini_window) is indeed what is wanted.
> >
> > Well, I _can_ think of such consequences. As I said, resize_mini_window
> > is called in many situations that don't involve completion, so setting
> > that variable to affect all of them is a bad idea. We need something
> > more fine-grained if we want to implement such a feature.
> >
>
> It would be very helpful if you could clarify what the consequences you
> think of are.
Just grep the sources for the callers of resize_mini_window, and you
will see what I mean. It is not safe to avoid affecting them using
the techniques you propose. The text itself should request such
special treatment.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 14:27:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Cc: 43572 <at> debbugs.gnu.org
> Date: Wed, 23 Sep 2020 22:47:05 +0000
> From: Gregory Heytings via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> > I think what I was getting at is that this "request" should come from
> > the minibuffer's text rather than from a variable.
>
> If this were possible, it would be even better indeed. An "importance"
> text property, which would inform redisplay (?) of the relative importance
> of the parts of the buffer. But implementing this is several orders of
> magnitude harder than implementing my proposal.
Actually testing for a certain text property in resize_mini_window
should be quite simple. We do similar things elsewhere in the display
code. So I see no reason to avoid that. It would definitely resolve
any issues with inadvertently affecting unrelated users of the
mini-window.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 14:28:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>
> There are more callers of resize_mini_widow than just those. It is not
> safe to assume that this can be handled only inside read_minibuf.
>
Please have a look at my corrected patch. It handles this inside
read_minibuf() *and* read_minibuf_unwind(), which AFAICS should make the
change to start_display_at_beginning_of_minibuffer last only for the time
it should last. If that's not the case, could you please provide a
recipe? I'm willing to improve the patch a second time if it's necessary.
>
> So I agree with Stefan that the text inserted into the minibuffer should
> itself indicate to the display engine that it wants to be displayed
> starting at BOB. That way we don't have to worry about inadvertently
> affecting other users of the mini-window.
>
That's a possibility indeed, and I agree that it would be even better, but
as I said this is several orders of magnitude harder to implement, and
unlikely to happen in a near future.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 14:35:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: ghe <at> sdf.org, 43572 <at> debbugs.gnu.org
> Date: Wed, 23 Sep 2020 19:18:39 -0400
>
> > This could be a useful new feature, but we still need to decide what
> > should the display engine do when the chunk of text marked with this
> > new indication (some text property, probably?) cannot all of it be
> > displayed. Should it then display only its first part, only its last
> > part, something else?
>
> I think this can be controlled with the position of point (which
> I guess should be presumed to be somewhere within the "important
> chunk"). The idea would be to maximize the amount of chunk that's
> displayed, but under the usual constraint that point is displayed.
Sure, point is important. But it doesn't solve the problem I had in
mind. Suppose you have text like this:
xxxxxxxxxxxxx[xxxxxxxxxxxx|xxxxxxxxxxxxxxxxxx]xxxxxxxxxxx
where [...] denotes the portion of text indicated as "important
chunk", and | denotes the position of point. Suppose further than the
available screen estate is insufficient to display all of the
"important chunk" -- which part would you want to see on display: the
part before point? after point? centered at point? something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 14:42:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>>>> I can't think of such unintended consequences. In the use case of
>>>> displaying completion candidates, this (the fact that it affects all
>>>> successive calls to resize_mini_window) is indeed what is wanted.
>>>
>>> Well, I _can_ think of such consequences. As I said,
>>> resize_mini_window is called in many situations that don't involve
>>> completion, so setting that variable to affect all of them is a bad
>>> idea. We need something more fine-grained if we want to implement
>>> such a feature.
>>>
>>
>> It would be very helpful if you could clarify what the consequences you
>> think of are.
>
> Just grep the sources for the callers of resize_mini_window, and you
> will see what I mean.
>
I did this. There are only seven calls to resize_mini_window().
>
> It is not safe to avoid affecting them using the techniques you propose.
>
Could you please provide a recipe which would demonstrate a problem with
the technique I propose? AFAICS, the flag is reset immediately when
read_minibuf() / read-from-minibuffer has ended.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 14:44:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Sep 2020 08:06:37 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: 43572 <at> debbugs.gnu.org
>
> - "master-icomplete-vertical-after-tab.png" is what a user would see with
> icomplete-mode activated and (setq icomplete-separator "\n") after having
> completed the last directory name with a TAB: the prompt and their input
> is completely hidden
Thanks, this subtle issue should now be fixed on master.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 14:53:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> - "master-icomplete-vertical-after-tab.png" is what a user would see
>> with icomplete-mode activated and (setq icomplete-separator "\n") after
>> having completed the last directory name with a TAB: the prompt and
>> their input is completely hidden
>
> Thanks, this subtle issue should now be fixed on master.
>
It is not, the only difference is that instead of "the prompt and their
input is completely hidden" one should now write "the prompt and the
largest part of their input is completely hidden".
Again, could you please provide a recipe which would demonstrate a problem
with the technique I propose?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 15:12:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Sep 2020 14:41:46 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: 43572 <at> debbugs.gnu.org
>
> > It is not safe to avoid affecting them using the techniques you propose.
> >
>
> Could you please provide a recipe which would demonstrate a problem with
> the technique I propose? AFAICS, the flag is reset immediately when
> read_minibuf() / read-from-minibuffer has ended.
That is true, but read_minibuf enters recursive-edit, and while that
is active, any call to resize_mini_window will be affected.
Using a text property for this is easy and mostly boilerplate, and it
completely avoids this issue.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 15:20:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Sep 2020 14:52:38 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: monnier <at> iro.umontreal.ca, 43572 <at> debbugs.gnu.org
>
> >> - "master-icomplete-vertical-after-tab.png" is what a user would see
> >> with icomplete-mode activated and (setq icomplete-separator "\n") after
> >> having completed the last directory name with a TAB: the prompt and
> >> their input is completely hidden
> >
> > Thanks, this subtle issue should now be fixed on master.
>
> It is not, the only difference is that instead of "the prompt and their
> input is completely hidden" one should now write "the prompt and the
> largest part of their input is completely hidden".
I mean the issue with the prompt being hidden after one TAB, but
appear after another TAB.
All the rest is just the consequence of the current policy to show the
last part of the stuff in the mini-window. (Note that with your
changes, one of the candidates isn't shown in the mini-window.)
There might be a misunderstanding here: I'm not claiming that the
changes I made yesterday and today are supposed to produce the same
effect as your proposed patch. I'm just making the display with
overlay-string behave (as much as possible) like display with normal
buffer text, that's all. Per bug#43519. I'm not saying that my
changes implement the feature you are asking for here.
> Again, could you please provide a recipe which would demonstrate a problem
> with the technique I propose?
I already explained why your design is problematic. And so did
Stefan. So I don't see why a recipe would be needed.
Implementation of such a feature should use text and/or overlay
properties to communicate the intent to the display code. That would
be much cleaner and safer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 16:10:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> Could you please provide a recipe which would demonstrate a problem
>> with the technique I propose? AFAICS, the flag is reset immediately
>> when read_minibuf() / read-from-minibuffer has ended.
>
> That is true, but read_minibuf enters recursive-edit, and while that is
> active, any call to resize_mini_window will be affected.
>
This seems to be a really minor problem. What kind of problems could
happen because during a recursive edit while icomplete or ido or ... is
active, redisplay is asked to start displaying at BOB? Do you really
believe this could lead to a non-minor problem?
>
> Using a text property for this is easy and mostly boilerplate, and it
> completely avoids this issue.
>
Then I wonder why this did not happen earlier (and wonder when it will
happen). A bug report about this exact problem has already been filed
five years ago (bug#24293). Five years ago. And the patch I'm proposing
is less than ten lines long, and would be most welcome today.
>
> I already explained why your design is problematic. And so did Stefan.
>
No, Stefan helped me to improve my design.
>
> So I don't see why a recipe would be needed.
>
Indeed, if the only remaining problem is that during a recursive edit
while icomplete or ido or ... is active, redisplay is asked to start
displaying at BOB instead of BOL, I don't think such a recipe would be
convincing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 16:21:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Sep 2020 16:09:25 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: 43572 <at> debbugs.gnu.org
>
> > That is true, but read_minibuf enters recursive-edit, and while that is
> > active, any call to resize_mini_window will be affected.
>
> This seems to be a really minor problem. What kind of problems could
> happen because during a recursive edit while icomplete or ido or ... is
> active, redisplay is asked to start displaying at BOB? Do you really
> believe this could lead to a non-minor problem?
Yes. There are third-party packages out there that do unimaginable
things when the user is prompted to enter his/her choice of something.
And in any case, we don't want to rely on luck in these matters, IME
the Murphy laws are very strong here.
> > Using a text property for this is easy and mostly boilerplate, and it
> > completely avoids this issue.
>
> Then I wonder why this did not happen earlier (and wonder when it will
> happen). A bug report about this exact problem has already been filed
> five years ago (bug#24293). Five years ago. And the patch I'm proposing
> is less than ten lines long, and would be most welcome today.
It didn't happen for the usual reasons: no one felt motivated enough
to sit down and do it.
Can I convince you to try implementing this via text properties? The
code will be very simple, I promise. And we are here to help if you
are unsure how to go about that.
> > I already explained why your design is problematic. And so did Stefan.
>
> No, Stefan helped me to improve my design.
He did both.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 16:27:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>>> Simply because I asked my window manager to always maximize Emacs frames.
>> Aha!
>> Yet another loophole!
> Hmm... Given the popularity (among a certain kind of users) of tiling
> window managers and the popularity (among a much larger kind of users) of
> using fullscreen apps, I don't think Emacs can expect to fully control the
> size of its frame. But indeed I see what you mean, ideally emacs -Q should
> give a frame of the same size everywhere. So it could perhaps make sense to
> try to do something like:
>
> (set-frame-width nil 80)
> (set-frame-height nil 40)
>
> (which works for me) at the end of the initialization process with "-q" or
> "-Q".
I definitely wouldn't want that for `-q`.
It might make sense in this case for `-Q`, but I'm not sure it's a good
tradeoff since we also want `emacs -Q` to mean something like "run with
no special configuration".
So maybe a better option is for the recipe to specify the frame's width.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 16:42:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> This seems to be a really minor problem. What kind of problems could
>> happen because during a recursive edit while icomplete or ido or ... is
>> active, redisplay is asked to start displaying at BOB? Do you really
>> believe this could lead to a non-minor problem?
>
> Yes. There are third-party packages out there that do unimaginable
> things when the user is prompted to enter his/her choice of something.
>
> And in any case, we don't want to rely on luck in these matters, IME the
> Murphy laws are very strong here.
>
I can't believe this, in particular given that the default value of
enable-recursive-minibuffers is nil. And in any case I'd say that it's to
the third-party packages to adapt to changes in Emacs (and I'm sure from
time to time there are changes here and there that force them to adapt
their code).
>> Then I wonder why this did not happen earlier (and wonder when it will
>> happen). A bug report about this exact problem has already been filed
>> five years ago (bug#24293). Five years ago. And the patch I'm
>> proposing is less than ten lines long, and would be most welcome today.
>
> It didn't happen for the usual reasons: no one felt motivated enough to
> sit down and do it.
>
> Can I convince you to try implementing this via text properties?
>
Of course you can. But only if you promise you will not reject what I do.
>
> The code will be very simple, I promise.
>
In fact, that's not motivating ;-)
>
> And we are here to help if you are unsure how to go about that.
>
Thank you, that's good to know.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 16:42:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> So I agree with Stefan that the text inserted into the minibuffer
> should itself indicate to the display engine that it wants to be
> displayed starting at BOB. That way we don't have to worry about
> inadvertently affecting other users of the mini-window.
It might be difficult/inconvenient to have the info directly in the
text, tho. Having it in a variable is not great (one of the
problems with it is that it depends on things like point so it's really
more "per-window" whereas variables are "per-buffer"), tho for the case
of minibuffers at least those buffers are normally never shown in more
than one window.
How 'bout using a window-parameter whose value should be an overlay
indicating the "area of focus", and then only obey this parameter if:
- the overlay is in the buffer that's being displayed.
- and window-point is lies within this overlay.
One more thing: there's a good argument to make that icomplete-vertical
should list the completions *above* the minibuffer's prompt rather than
below (so as not to affect the positions of the minibuffer's prompt so
much). But in that case, the part of the overlay's after/before string
(when too long) which should be truncated (when the mini-window is too
small) is the beginning, whereas IIUC the current redisplay is unable to
display "the end" of an overlay's after/before string unless it also
shows its beginning.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 16:46:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> where [...] denotes the portion of text indicated as "important
> chunk", and | denotes the position of point. Suppose further than the
> available screen estate is insufficient to display all of the
> "important chunk" -- which part would you want to see on display: the
> part before point? after point? centered at point? something else?
I think either of those would be fine, so it should be decided by the
usual scrolling constraints (i.e. don't scroll if not needed, obey
scroll-conservatively, ...).
IOW, by default if scrolling was needed anyway and scroll-conservatively
is not set, I'd expect "centered at point".
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 16:55:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Gregory Heytings <ghe <at> sdf.org>, 43572 <at> debbugs.gnu.org
> Date: Thu, 24 Sep 2020 12:40:59 -0400
>
> > So I agree with Stefan that the text inserted into the minibuffer
> > should itself indicate to the display engine that it wants to be
> > displayed starting at BOB. That way we don't have to worry about
> > inadvertently affecting other users of the mini-window.
>
> It might be difficult/inconvenient to have the info directly in the
> text, tho.
I don't think I see why it would be difficult/inconvenient. Can you
explain?
> How 'bout using a window-parameter whose value should be an overlay
> indicating the "area of focus", and then only obey this parameter if:
> - the overlay is in the buffer that's being displayed.
> - and window-point is lies within this overlay.
This sounds like the same idea of a text property, only with an
overlay and a more complicated test for applicability. When I said
"text property", I meant both text and overlay property, so if you
think your proposal above is less difficult/inconvenient, then using
just an overlay would be even simpler, no? Or what am I missing?
> One more thing: there's a good argument to make that icomplete-vertical
> should list the completions *above* the minibuffer's prompt rather than
> below (so as not to affect the positions of the minibuffer's prompt so
> much). But in that case, the part of the overlay's after/before string
> (when too long) which should be truncated (when the mini-window is too
> small) is the beginning, whereas IIUC the current redisplay is unable to
> display "the end" of an overlay's after/before string unless it also
> shows its beginning.
Yes, we cannot start a window's display in the middle of an overlay
string.
In general, display and overlay strings were not intended for 75%
(maybe more) of the uses they get nowadays, and it shows.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 17:00:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: ghe <at> sdf.org, 43572 <at> debbugs.gnu.org
> Date: Thu, 24 Sep 2020 12:44:56 -0400
>
> > where [...] denotes the portion of text indicated as "important
> > chunk", and | denotes the position of point. Suppose further than the
> > available screen estate is insufficient to display all of the
> > "important chunk" -- which part would you want to see on display: the
> > part before point? after point? centered at point? something else?
>
> I think either of those would be fine, so it should be decided by the
> usual scrolling constraints (i.e. don't scroll if not needed, obey
> scroll-conservatively, ...).
>
> IOW, by default if scrolling was needed anyway and scroll-conservatively
> is not set, I'd expect "centered at point".
The code which implements automatic scrolling was not written with the
mini-window in mind. In fact, we would like not to allow any
scrolling at all there.
So perhaps relying on scrolling could be fine in normal windows, it
will most probably do the wrong thing in mini-windows. And even in
normal windows, it will probably work only by sheer luck, because the
design there cares about the context of point, and that is not
necessarily what you want with "important chunks".
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 17:04:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Sep 2020 16:40:58 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: 43572 <at> debbugs.gnu.org
>
> > And in any case, we don't want to rely on luck in these matters, IME the
> > Murphy laws are very strong here.
>
> I can't believe this, in particular given that the default value of
> enable-recursive-minibuffers is nil.
You again are thinking only about uses of mini-window for editing in
the minibuffer. But that is not the only use of the mini-window.
And even in its use for the minibuffer, many users enable recursive
minibuffers. I would not be surprised if some specialized modes and
packages enabled it for their operations.
> And in any case I'd say that it's to the third-party packages to
> adapt to changes in Emacs
If we break too many important packages, we will have bug reports
which we will be unable to ignore. Emacs is expected to not break
third-party code too much too hard.
> > Can I convince you to try implementing this via text properties?
>
> Of course you can. But only if you promise you will not reject what I do.
If the implementation is clean, and doesn't present backward
compatibility problems, why would I want to reject it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Thu, 24 Sep 2020 21:52:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 43572 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> I can't believe this, in particular given that the default value of
>> enable-recursive-minibuffers is nil.
>
> You again are thinking only about uses of mini-window for editing in the
> minibuffer. But that is not the only use of the mini-window.
>
I'm not sure I understand what you mean, but it seems to me that these
other uses of the mini-window are not at all affected by the proposed
patch, given that `start-display-at-beginning-of-minibuffer' is reset
immediately when read_minibuf() / read-from-minibuffer has ended.
>
> And even in its use for the minibuffer, many users enable recursive
> minibuffers. I would not be surprised if some specialized modes and
> packages enabled it for their operations.
>
If this case is important, the attached corrected patch also disables
setting `start-display-at-beginning-of-minibuffer' in recursive
minibuffers, that is, it limits the effect of that variable to
non-recursive minibuffers.
I'll wait until you and Stefan agree on the way to solve that problem in a
better way to start working on this. In his last mail he is apparently
not sure anymore that using text properties to do this, as he suggested
yesterday, is the best solution.
[start-display-at-beginning-of-minibuffer.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 25 Sep 2020 07:00:01 GMT)
Full text and
rfc822 format available.
Message #116 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Sep 2020 21:51:43 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: 43572 <at> debbugs.gnu.org
>
> >> I can't believe this, in particular given that the default value of
> >> enable-recursive-minibuffers is nil.
> >
> > You again are thinking only about uses of mini-window for editing in the
> > minibuffer. But that is not the only use of the mini-window.
>
> I'm not sure I understand what you mean, but it seems to me that these
> other uses of the mini-window are not at all affected by the proposed
> patch, given that `start-display-at-beginning-of-minibuffer' is reset
> immediately when read_minibuf() / read-from-minibuffer has ended.
I remind you the fact that read_minibuf enters recursive-edit, during
which any of the other callers of resize_mini_window can be called.
> > And even in its use for the minibuffer, many users enable recursive
> > minibuffers. I would not be surprised if some specialized modes and
> > packages enabled it for their operations.
>
> If this case is important, the attached corrected patch also disables
> setting `start-display-at-beginning-of-minibuffer' in recursive
> minibuffers, that is, it limits the effect of that variable to
> non-recursive minibuffers.
That's a limitation I'd prefer not to impose. It also doesn't affect
the other callers of resize_mini_window.
> I'll wait until you and Stefan agree on the way to solve that problem in a
> better way to start working on this. In his last mail he is apparently
> not sure anymore that using text properties to do this, as he suggested
> yesterday, is the best solution.
Yes, I'm still unsure why Stefan said that, and am waiting for his
elaborations.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 25 Sep 2020 08:35:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> I'm not sure I understand what you mean, but it seems to me that these
>> other uses of the mini-window are not at all affected by the proposed
>> patch, given that `start-display-at-beginning-of-minibuffer' is reset
>> immediately when read_minibuf() / read-from-minibuffer has ended.
>
> I remind you the fact that read_minibuf enters recursive-edit, during
> which any of the other callers of resize_mini_window can be called.
>
Now I think I understand what you mean. Mini-windows are used for
minibuffers and for the echo area. So for example, when
`start-display-at-beginning-of-minibuffer' is set while icomplete is
active in a frame, a call to `message' in another frame will display the
first part of the string instead of its last part if the string is too
large. This seems like a really minor problem.
>>> And even in its use for the minibuffer, many users enable recursive
>>> minibuffers. I would not be surprised if some specialized modes and
>>> packages enabled it for their operations.
>>
>> If this case is important, the attached corrected patch also disables
>> setting `start-display-at-beginning-of-minibuffer' in recursive
>> minibuffers, that is, it limits the effect of that variable to
>> non-recursive minibuffers.
>
> That's a limitation I'd prefer not to impose.
>
I would also prefer not to impose that limitation, I added it because you
asked it (or at least that's what I understood). I think the second patch
I sent is the best and simplest one. I do agree with you that it's an
ad-hoc solution, but there are other such ad-hoc solutions in Emacs, for
example the `minibuffer-completing-file-name' variable, which even uses a
"neither true nor false" intermediate state in recursive minibuffers.
Anyway, I won't argue further, at this point it seems clear that you don't
want the patch I proposed.
A remark on what you wrote yesterday:
>
> I'm not claiming that the changes I made yesterday and today are
> supposed to produce the same effect as your proposed patch. I'm just
> making the display with overlay-string behave (as much as possible) like
> display with normal buffer text, that's all. Per bug#43519. I'm not
> saying that my changes implement the feature you are asking for here.
>
In fact these changes are, IMO, very regrettable, because they solve 95%
of the problems that have been discussed in bug#24293, bug#39379,
bug#43519 and bug#43572 (and perhaps others), and the remaining 5% will
have to be solved another way (by text properties if that's what you agree
on with Stefan).
This means that those who were trying to solve the problems in the
above-mentioned bugs will be misled in thinking that they are now solved
(if they don't immediately see these remaining 5%), and to not make the
effort to use the (not yet implemented) correct solution.
I don't think you will do this, but please, please: revert these changes.
>> I'll wait until you and Stefan agree on the way to solve that problem
>> in a better way to start working on this. In his last mail he is
>> apparently not sure anymore that using text properties to do this, as
>> he suggested yesterday, is the best solution.
>
> Yes, I'm still unsure why Stefan said that, and am waiting for his
> elaborations.
>
Okay, I'm waiting for the conclusion of that discussion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 25 Sep 2020 09:15:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 25 Sep 2020 08:34:50 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: 43572 <at> debbugs.gnu.org
>
> > I remind you the fact that read_minibuf enters recursive-edit, during
> > which any of the other callers of resize_mini_window can be called.
>
> Now I think I understand what you mean. Mini-windows are used for
> minibuffers and for the echo area. So for example, when
> `start-display-at-beginning-of-minibuffer' is set while icomplete is
> active in a frame, a call to `message' in another frame will display the
> first part of the string instead of its last part if the string is too
> large.
Yes. And there are more callers of resize_mini_window than just
'message', so what you say above is just one such problematic
scenario.
> This seems like a really minor problem.
It is still a problem, and what looks minor to us might not be minor
in some valid use case out there. IME, people write code and even
entire packages around some assumption about how Emacs works in
specific cases. Changes that break those assumptions will not be
welcome, to say the least.
> >> If this case is important, the attached corrected patch also disables
> >> setting `start-display-at-beginning-of-minibuffer' in recursive
> >> minibuffers, that is, it limits the effect of that variable to
> >> non-recursive minibuffers.
> >
> > That's a limitation I'd prefer not to impose.
>
> I would also prefer not to impose that limitation, I added it because you
> asked it (or at least that's what I understood).
I didn't ask for the limitation, I pointed out a problem with the
design you were proposing. I'd prefer that the design and the
implementation of this feature did not impose such limitations. Emacs
generally behaves the same on any level of minibuffer recursion, and
I'd like us not to violate that with this feature.
> > I'm not claiming that the changes I made yesterday and today are
> > supposed to produce the same effect as your proposed patch. I'm just
> > making the display with overlay-string behave (as much as possible) like
> > display with normal buffer text, that's all. Per bug#43519. I'm not
> > saying that my changes implement the feature you are asking for here.
>
> In fact these changes are, IMO, very regrettable, because they solve 95%
> of the problems that have been discussed in bug#24293, bug#39379,
> bug#43519 and bug#43572 (and perhaps others), and the remaining 5% will
> have to be solved another way (by text properties if that's what you agree
> on with Stefan).
They solve the issue pointed out by Stefan in bug#43519. That they,
by sheer luck, also solve some of the other issues is just that --
sheer luck. I don't claim and didn't intend to solve all the
problems, in particular the issue discussed in this bug report. They
are related, but different issues.
> This means that those who were trying to solve the problems in the
> above-mentioned bugs will be misled in thinking that they are now solved
> (if they don't immediately see these remaining 5%), and to not make the
> effort to use the (not yet implemented) correct solution.
I really don't see why that would be the case. If someone is
motivated to solve whatever is left of those other problems, they will
solve them, or at least will point out which aspects of them remain
unresolved.
> I don't think you will do this, but please, please: revert these changes.
Reverting those changes would be a very strange thing to do. Those
changes solve a specific problem, and they solve it cleanly. That
other problems partially remain just means more changes are necessary.
In particular, the issues discussed here are a new feature which
didn't exist until now; reverting fixes for an existing problem
because they fail to introduce a new feature makes very little sense
to me.
Btw, there's nothing wrong in principle with installing a partial
solution for a problem (even though that's not what I meant to do with
the changes that resolve bug#43519). We can and do decide sometimes
that it's a good idea to install a partial fix if the part fixed is
important enough, or if a comprehensive solution is too dangerous, or
for any other valid concern. This is not uncommon in Emacs
development.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 25 Sep 2020 10:15:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> In fact these changes are, IMO, very regrettable, because they solve
>> 95% of the problems that have been discussed in bug#24293, bug#39379,
>> bug#43519 and bug#43572 (and perhaps others), and the remaining 5% will
>> have to be solved another way (by text properties if that's what you
>> agree on with Stefan).
>
> They solve the issue pointed out by Stefan in bug#43519. That they, by
> sheer luck, also solve some of the other issues is just that -- sheer
> luck. I don't claim and didn't intend to solve all the problems, in
> particular the issue discussed in this bug report. They are related,
> but different issues.
>
There have been several misunderstandings in these discussions. In
bug#43519, Stefan pointed out an issue with a simple recipe to exhibit a
more general problem. This simple recipe, because it was simple, did not
demonstrate all aspects of the problem. In particular, it only
demonstrated what he called "horizontal scrolling", when the problem in
fact involves both horizontal _and vertical_ scrolling.
I'll remind a second time the discussion on emacs-devel that prompted
Stefan to file bug#43519:
Ergus: [To implement icomplete-vertical] we need to add the exact amount
of lines as accurate[ly] as possible.
Stefan: I *strongly* recommend you design the behavior under the
assumption that it's OK if there are a few more lines in the (mini)buffer
than are actually visible.
Me: If there are too many candidates the prompt disappears, leaving the
cursor at the beginning of the minibuffer, which is counterintuitive. A
simple example: after (setq max-mini-window-height 1), with "M-x a" the
"M-x" prompt and the "a" disappear.
Stefan: That can (and should) be fixed without having to reduce the number
of candidates inserted in the (mini)buffer.
Ergus: It will be great if you give me an idea about how to do that.
Stefan: You need to figure out why the redisplay decides to hide the
prompt rather than some other part of the (mini)buffer.
Stefan files bug#43519 (with the "M-x a" example).
As you see, the point is to keep the prompt visible, not just to avoid
horizontal scrolling. And Stefan refers to bug#24293 and bug#39379, where
the same problem (the prompt becomes invisible) is explained and
workarounds are discussed.
>> I don't think you will do this, but please, please: revert these
>> changes.
>
> Reverting those changes would be a very strange thing to do. Those
> changes solve a specific problem, and they solve it cleanly.
>
They partially solve a specific problem. This specific problem exists
only in the context of inserting completion candidates at EOB with an
overlay. And the specific problem is not horizontal scrolling, the
specific problem is the prompt that becomes invisible. I clearly said
(and explained) in bug#43519 that to solve that problem it is necessary to
start display at BOB, and you preferred to implement a change that starts
display at BOL. I think these changes are misleading.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 25 Sep 2020 11:18:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 25 Sep 2020 10:14:47 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: 43572 <at> debbugs.gnu.org
>
> >> In fact these changes are, IMO, very regrettable, because they solve
> >> 95% of the problems that have been discussed in bug#24293, bug#39379,
> >> bug#43519 and bug#43572 (and perhaps others), and the remaining 5% will
> >> have to be solved another way (by text properties if that's what you
> >> agree on with Stefan).
> >
> > They solve the issue pointed out by Stefan in bug#43519. That they, by
> > sheer luck, also solve some of the other issues is just that -- sheer
> > luck. I don't claim and didn't intend to solve all the problems, in
> > particular the issue discussed in this bug report. They are related,
> > but different issues.
> >
>
> There have been several misunderstandings in these discussions. In
> bug#43519, Stefan pointed out an issue with a simple recipe to exhibit a
> more general problem. This simple recipe, because it was simple, did not
> demonstrate all aspects of the problem. In particular, it only
> demonstrated what he called "horizontal scrolling", when the problem in
> fact involves both horizontal _and vertical_ scrolling.
I'll leave it to Stefan to say what he meant, but here's my
understanding: the problem Stefan complained about in bug#43519 was
only what you call "horizontal scrolling", and he complained about it
because that didn't happen with text that came from a buffer (as
opposed to text from an overlay string). This is the part that I
fixed.
What you call "vertical scrolling" happens with both buffer text and
overlay strings, and is the subject of this bug report. It's a
separate issue.
> As you see, the point is to keep the prompt visible, not just to avoid
> horizontal scrolling.
The prompt cannot always be kept visible as long as we display the
last portion of the text in the mini-window. The code is explicitly
designed to enforce this, so it is not a bug, but the intended
behavior. You suggest in this bug report to add a feature that allows
to change that policy. But that is an issue separate from bug#43519,
and thus not directly related to the changes I installed to fix that
bug.
> And Stefan refers to bug#24293 and bug#39379, where the same problem
> (the prompt becomes invisible) is explained and workarounds are
> discussed.
I disagree that it's the same problem. Part of what is described
there is the problem fixed in bug#43519, the other part is the
intended behavior.
> > Reverting those changes would be a very strange thing to do. Those
> > changes solve a specific problem, and they solve it cleanly.
>
> They partially solve a specific problem. This specific problem exists
> only in the context of inserting completion candidates at EOB with an
> overlay. And the specific problem is not horizontal scrolling, the
> specific problem is the prompt that becomes invisible. I clearly said
> (and explained) in bug#43519 that to solve that problem it is necessary to
> start display at BOB, and you preferred to implement a change that starts
> display at BOL. I think these changes are misleading.
And I disagree, as explained above. So let's agree to disagree,
because these back-and-forth messages, where we both say the same
things over and over and over again, are already too many to be
useful.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 25 Sep 2020 11:35:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> And Stefan refers to bug#24293 and bug#39379, where the same problem
>> (the prompt becomes invisible) is explained and workarounds are
>> discussed.
>
> I disagree that it's the same problem. Part of what is described there
> is the problem fixed in bug#43519, the other part is the intended
> behavior.
>
Yet it is the same problem. The fact that these bugs use simple examples
(presumably because their authors did not yet investigate the more complex
cases) does not mean that their bug reports mean something else than what
they clearly say: "the prompt is not visible".
>
> And I disagree, as explained above. So let's agree to disagree, because
> these back-and-forth messages, where we both say the same things over
> and over and over again, are already too many to be useful.
>
I agree to disagree.
Please tell me when you and Stefan agree on a better / the best way to
solve the current problem. I'll be silent till then.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 25 Sep 2020 18:32:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 43572 <at> debbugs.gnu.org (full text, mbox):
A simple recipe to demonstrate the problem:
emacs -Q
(let (w bd)
(setq w 60)
(setq bd (concat (temporary-file-directory) (make-string w ?a) "/"))
(dolist (d '("a" "b" "c" "d" "e")) (make-directory (concat bd d) t))
(setq default-directory bd)
(set-frame-height nil 20)
(set-frame-width nil (+ (length bd) 10))
(icomplete-mode)
(setq icomplete-separator "\n")
(call-interactively 'insert-file))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Sun, 27 Sep 2020 16:12:01 GMT)
Full text and
rfc822 format available.
Message #137 received at 43572 <at> debbugs.gnu.org (full text, mbox):
Ping!
> Date: Thu, 24 Sep 2020 19:54:36 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: ghe <at> sdf.org, 43572 <at> debbugs.gnu.org
>
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: Gregory Heytings <ghe <at> sdf.org>, 43572 <at> debbugs.gnu.org
> > Date: Thu, 24 Sep 2020 12:40:59 -0400
> >
> > > So I agree with Stefan that the text inserted into the minibuffer
> > > should itself indicate to the display engine that it wants to be
> > > displayed starting at BOB. That way we don't have to worry about
> > > inadvertently affecting other users of the mini-window.
> >
> > It might be difficult/inconvenient to have the info directly in the
> > text, tho.
>
> I don't think I see why it would be difficult/inconvenient. Can you
> explain?
>
> > How 'bout using a window-parameter whose value should be an overlay
> > indicating the "area of focus", and then only obey this parameter if:
> > - the overlay is in the buffer that's being displayed.
> > - and window-point is lies within this overlay.
>
> This sounds like the same idea of a text property, only with an
> overlay and a more complicated test for applicability. When I said
> "text property", I meant both text and overlay property, so if you
> think your proposal above is less difficult/inconvenient, then using
> just an overlay would be even simpler, no? Or what am I missing?
>
> > One more thing: there's a good argument to make that icomplete-vertical
> > should list the completions *above* the minibuffer's prompt rather than
> > below (so as not to affect the positions of the minibuffer's prompt so
> > much). But in that case, the part of the overlay's after/before string
> > (when too long) which should be truncated (when the mini-window is too
> > small) is the beginning, whereas IIUC the current redisplay is unable to
> > display "the end" of an overlay's after/before string unless it also
> > shows its beginning.
>
> Yes, we cannot start a window's display in the middle of an overlay
> string.
>
> In general, display and overlay strings were not intended for 75%
> (maybe more) of the uses they get nowadays, and it shows.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Sun, 27 Sep 2020 21:53:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> This sounds like the same idea of a text property, only with an
>> overlay and a more complicated test for applicability. When I said
>> "text property", I meant both text and overlay property, so if you
>> think your proposal above is less difficult/inconvenient, then using
>> just an overlay would be even simpler, no? Or what am I missing?
My motivation was to solve the issue of finding the relevant overlay.
But yes, we could also just try and find "the overlay that covers point
and which has a non-nil `scroll-focus` property". We'll just have to be
careful to properly handle the case where point is exactly at
`overlay-start` or `overlay-end`.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Sun, 27 Sep 2020 22:00:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> IOW, by default if scrolling was needed anyway and scroll-conservatively
>> is not set, I'd expect "centered at point".
> The code which implements automatic scrolling was not written with the
> mini-window in mind. In fact, we would like not to allow any
> scrolling at all there.
When the window is big enough to show the whole content, I agree, but as
soon as the buffer is bigger then we need to handle scrolling, just
like elsewhere.
> So perhaps relying on scrolling could be fine in normal windows, it
> will most probably do the wrong thing in mini-windows.
That's not my experience so far. I do find that the
`scroll-conservatively` is generally desired for the mini-window
(whereas I don't generally like it in normal windows), but other than
that I find (much to my surprise) that the generic scrolling code
behaves just as well as the ad-hoc scrolling code in resize_mini_window.
Thinking about it, maybe I shouldn't be surprised: the generic code is
used much more often and has been tuned quite heavily over the years to
provide good behavior is the vast majority of cases, so it's only
"normal" that it should behave nicely in this case as well.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Mon, 28 Sep 2020 06:11:01 GMT)
Full text and
rfc822 format available.
Message #146 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: ghe <at> sdf.org, 43572 <at> debbugs.gnu.org
> Date: Sun, 27 Sep 2020 17:52:21 -0400
>
> >> This sounds like the same idea of a text property, only with an
> >> overlay and a more complicated test for applicability. When I said
> >> "text property", I meant both text and overlay property, so if you
> >> think your proposal above is less difficult/inconvenient, then using
> >> just an overlay would be even simpler, no? Or what am I missing?
>
> My motivation was to solve the issue of finding the relevant overlay.
> But yes, we could also just try and find "the overlay that covers point
> and which has a non-nil `scroll-focus` property". We'll just have to be
> careful to properly handle the case where point is exactly at
> `overlay-start` or `overlay-end`.
I actually thought about putting the text property or overlay on the
first character of the text inserted into the minibuffer, something
that can be done in a minibuffer-setup-hook. This way, it will be
easy to find. Of course, having that on any other part of the text
will not make the job much harder, either.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Mon, 28 Sep 2020 06:21:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: ghe <at> sdf.org, 43572 <at> debbugs.gnu.org
> Date: Sun, 27 Sep 2020 17:59:02 -0400
>
> >> IOW, by default if scrolling was needed anyway and scroll-conservatively
> >> is not set, I'd expect "centered at point".
> > The code which implements automatic scrolling was not written with the
> > mini-window in mind. In fact, we would like not to allow any
> > scrolling at all there.
>
> When the window is big enough to show the whole content, I agree, but as
> soon as the buffer is bigger then we need to handle scrolling, just
> like elsewhere.
>
> > So perhaps relying on scrolling could be fine in normal windows, it
> > will most probably do the wrong thing in mini-windows.
>
> That's not my experience so far. I do find that the
> `scroll-conservatively` is generally desired for the mini-window
> (whereas I don't generally like it in normal windows), but other than
> that I find (much to my surprise) that the generic scrolling code
> behaves just as well as the ad-hoc scrolling code in resize_mini_window.
Maybe it's 80% correct, but my worry is exactly those remaining 20%.
It is they that generate most of the bug reports in Emacs nowadays.
The fact that you find scroll-conservatively improve the results is
already a clear sign that the scrolling mechanism is not fit very well
for such small windows, especially when they are used for user
interaction. And if you look at the window-display code, you will see
there several code fragments dealing with the cases of a text line
which is as tall or taller than the window, whose results are frankly
questionable, and whose only justification is that those cases "should
not happen". What you suggest will make the probability of that
happening much higher, and in use cases where it will hurt.
And all this is even before we take the massive use of overlay strings
in some completion features.
So no, I cannot agree that your experience is evidence good enough for
allowing GP Emacs scrolling code to handle mini-window display.
> Thinking about it, maybe I shouldn't be surprised: the generic code is
> used much more often and has been tuned quite heavily over the years to
> provide good behavior is the vast majority of cases, so it's only
> "normal" that it should behave nicely in this case as well.
That is true, but it wasn't tuned to the use cases we meet every day
in the mini-windows. We generally don't allow a window to become too
small in height, but that happens with mini-windows all the time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Mon, 28 Sep 2020 13:25:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> I actually thought about putting the text property or overlay on the
> first character of the text inserted into the minibuffer,
I don't understand what data you intend to put this way.
The overlay I proposed carries fundamentally 2 pieces of info: the
beginning position and the end position of the "scroll focus".
So if it needs to cover the first char, you can't use `overlay-start` to
carry the first info.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Mon, 28 Sep 2020 13:31:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> That's not my experience so far. I do find that the
>> `scroll-conservatively` is generally desired for the mini-window
>> (whereas I don't generally like it in normal windows), but other than
>> that I find (much to my surprise) that the generic scrolling code
>> behaves just as well as the ad-hoc scrolling code in resize_mini_window.
> Maybe it's 80% correct, but my worry is exactly those remaining 20%.
Same here. I only tried that code in very limited circumstances and
I know there are many more scenarios out there that I can't even begin
to imagine.
> So no, I cannot agree that your experience is evidence good enough for
> allowing GP Emacs scrolling code to handle mini-window display.
I definitely don't claim it's good enough to get rid of the ad-hoc
scrolling code, but I think it is worth pursuing.
How 'bout we add a config `minibuffer-scroll-generic`?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Mon, 28 Sep 2020 13:43:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: ghe <at> sdf.org, 43572 <at> debbugs.gnu.org
> Date: Mon, 28 Sep 2020 09:24:34 -0400
>
> > I actually thought about putting the text property or overlay on the
> > first character of the text inserted into the minibuffer,
>
> I don't understand what data you intend to put this way.
Just "start at BOB" indication.
> The overlay I proposed carries fundamentally 2 pieces of info: the
> beginning position and the end position of the "scroll focus".
We could still put this on the first character, and have the value of
the property be a cons cell with these two positions, no?
IOW, the information doesn't have to be on the characters which it
describes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Mon, 28 Sep 2020 13:45:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: ghe <at> sdf.org, 43572 <at> debbugs.gnu.org
> Date: Mon, 28 Sep 2020 09:30:46 -0400
>
> How 'bout we add a config `minibuffer-scroll-generic`?
I don't mind, but who would use that, and why?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Mon, 28 Sep 2020 15:54:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> I actually thought about putting the text property or overlay on the
> first character of the text inserted into the minibuffer, something
> that can be done in a minibuffer-setup-hook. This way, it will be
> easy to find. Of course, having that on any other part of the text
> will not make the job much harder, either.
Caveat: haven't been following this thread.
I put text properties on the first char of the
minibuffer prompt, for some special purposes.
Dunno whether that makes sense in your context.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Mon, 28 Sep 2020 16:58:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> The overlay I proposed carries fundamentally 2 pieces of info: the
>> beginning position and the end position of the "scroll focus".
> We could still put this on the first character,
Indeed, that's an option, but it doesn't seem particularly handy.
Not necessarily worse than a window-property or a buffer-local value,
admittedly.
> and have the value of the property be a cons cell with these two
> positions, no?
An overlay is a handy abstraction for "pair of two positions in the same
buffer", with extra niceties such as the `evaporate` property.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Mon, 28 Sep 2020 16:59:02 GMT)
Full text and
rfc822 format available.
Message #170 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> How 'bout we add a config `minibuffer-scroll-generic`?
> I don't mind, but who would use that,
Those people I'd manage to con into setting it?
> and why?
To help collect info about it?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 02 Oct 2020 15:41:01 GMT)
Full text and
rfc822 format available.
Message #173 received at 43572 <at> debbugs.gnu.org (full text, mbox):
Hi Stefan and Eli,
Thanks for your comments.
This feature request can be closed. I found a solution that works without
changing anything in Emacs core.
I still think that the changes introduced by Eli in xdisp.c should be
reverted. They are not a solution for the problem, and they change a
long-standing behavior of a central part of Emacs, which might break or
cause other problems with third-party packages that do unimaginable things
with miniwindows.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 02 Oct 2020 16:09:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> I still think that the changes introduced by Eli in xdisp.c should be
> reverted. They are not a solution for the problem, and they change
> a long-standing behavior of a central part of Emacs, which might break or
> cause other problems with third-party packages that do unimaginable things
> with miniwindows.
Like any change, Eli's change can introduce regressions, but so far
I haven't seen any clear regression, whereas we do know of one very
clear improvement.
So reverting would be ill-advised at this point.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 02 Oct 2020 16:12:01 GMT)
Full text and
rfc822 format available.
Message #179 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 02 Oct 2020 15:40:42 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
>
> This feature request can be closed. I found a solution that works without
> changing anything in Emacs core.
As I wrote on emacs-devel, I don't like the solution you've found.
You are, of course, free to use it in your code, but I don't think we
should adopt it in core Emacs.
> I still think that the changes introduced by Eli in xdisp.c should be
> reverted.
You've said this before, several times, and I explained why that would
be a bad idea, to say the least. Reiterating that now sounds like
bullying, and why would you want to do something like that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 02 Oct 2020 16:26:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> This feature request can be closed. I found a solution that works
>> without changing anything in Emacs core.
>
> As I wrote on emacs-devel, I don't like the solution you've found. You
> are, of course, free to use it in your code, but I don't think we should
> adopt it in core Emacs.
>
Your reaction is saddening. I'm very sorry to read this, but you rejected
all my attempts to solve that problem so far, so that's not surprising.
I'd bet that there are many places in Emacs where similar "quick and
dirty" hacks are used. At least I did my best to solve that problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 02 Oct 2020 19:31:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 43572 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 02 Oct 2020 16:25:05 +0000
> From: Gregory Heytings <ghe <at> sdf.org>
> cc: monnier <at> iro.umontreal.ca, 43572 <at> debbugs.gnu.org
>
> Your reaction is saddening. I'm very sorry to read this, but you rejected
> all my attempts to solve that problem so far, so that's not surprising.
I rejected what clearly looked like unsafe and unclean design. Please
respect the opinions of those who have deeper knowledge of Emacs
internals and many years of experience hacking them. Your insistence
on doing things in sub-optimal ways when much better ways are at hand
makes it hard to discuss these issues with you and arrive at sound
solutions that can be trusted not to produce bugs in the future.
> I'd bet that there are many places in Emacs where similar "quick and
> dirty" hacks are used.
Actually, no, there aren't. "Quick and dirty" is okay for rapid
prototyping and presenting a POC, but not for changes that get
admitted into core.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 02 Oct 2020 21:50:01 GMT)
Full text and
rfc822 format available.
Message #188 received at 43572 <at> debbugs.gnu.org (full text, mbox):
>> Your reaction is saddening. I'm very sorry to read this, but you
>> rejected all my attempts to solve that problem so far, so that's not
>> surprising.
>
> I rejected what clearly looked like unsafe and unclean design. Please
> respect the opinions of those who have deeper knowledge of Emacs
> internals and many years of experience hacking them. Your insistence on
> doing things in sub-optimal ways when much better ways are at hand makes
> it hard to discuss these issues with you and arrive at sound solutions
> that can be trusted not to produce bugs in the future.
>
I won't go in that direction, I will not start a public quarrel with you.
I can only repeat that your reaction is saddening.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#43572; Package
emacs.
(Fri, 29 Apr 2022 14:03:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 43572 <at> debbugs.gnu.org (full text, mbox):
Gregory Heytings <ghe <at> sdf.org> writes:
> This feature request can be closed. I found a solution that works
> without changing anything in Emacs core.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
Skimming this bug thread, it seems like there's room for improvement in
how Emacs displays these things, but it seems unlikely that there'll be
further progress here, so I'm closing this bug report. The approach of
marking certain text for the display to pick up seems possible, but the
main use cases seem to be gone now (if I read correctly, which I may not
have).
If further work should be done here, I think opening a new bug report
and restating the aims would be the way forward.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
43572 <at> debbugs.gnu.org and Gregory Heytings <ghe <at> sdf.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Fri, 29 Apr 2022 14:03:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 28 May 2022 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 333 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.