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
15 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
> From: Stefan Monnier <[hidden email]>
> Date: Wed, 23 Sep 2020 14:33:13 -0400
> Cc: [hidden email]
>
> 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?



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

Stefan Monnier
> 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




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
> From: Stefan Monnier <[hidden email]>
> Cc: [hidden email],  [hidden email]
> 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?



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

Stefan Monnier
> 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




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
> From: Stefan Monnier <[hidden email]>
> Cc: [hidden email],  [hidden email]
> 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".



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

Stefan Monnier
>> 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




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
> From: Stefan Monnier <[hidden email]>
> Cc: [hidden email],  [hidden email]
> 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.



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

Stefan Monnier
>> 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




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
> From: Stefan Monnier <[hidden email]>
> Cc: [hidden email],  [hidden email]
> 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?



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

Stefan Monnier
>> 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




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

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.



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

Stefan Monnier
> 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




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: Fri, 02 Oct 2020 15:40:42 +0000
> From: Gregory Heytings <[hidden email]>
>
> 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?



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, 02 Oct 2020 16:25:05 +0000
> From: Gregory Heytings <[hidden email]>
> cc: [hidden email], [hidden email]
>
> 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.



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

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