bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Eli Zaretskii
> 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" <[hidden email]>
>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list

>> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Eli Zaretskii
> Date: Wed, 23 Sep 2020 19:15:40 +0000
> From: Gregory Heytings <[hidden email]>
> cc: [hidden email]
>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list

>
> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list
In reply to this post by Eli Zaretskii

>>> 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().



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Eli Zaretskii
In reply to this post by Emacs - Bugs mailing list
> Date: Wed, 23 Sep 2020 20:15:54 +0000
> From: Gregory Heytings <[hidden email]>
> cc: [hidden email]
>
> >> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list

>>>> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Eli Zaretskii
> Date: Thu, 24 Sep 2020 14:41:46 +0000
> From: Gregory Heytings <[hidden email]>
> cc: [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list

>> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Eli Zaretskii
> Date: Thu, 24 Sep 2020 16:09:25 +0000
> From: Gregory Heytings <[hidden email]>
> cc: [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list

>> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Eli Zaretskii
> Date: Thu, 24 Sep 2020 16:40:58 +0000
> From: Gregory Heytings <[hidden email]>
> cc: [hidden email]
>
> > 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?



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list

>> 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 (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list

>> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list

>> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Eli Zaretskii
> Date: Fri, 25 Sep 2020 10:14:47 +0000
> From: Gregory Heytings <[hidden email]>
> cc: [hidden email]
>
> >> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list

>> 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.



Reply | Threaded
Open this post in threaded view
|

bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones

Emacs - Bugs mailing list
In reply to this post by Eli Zaretskii

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))