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 08:34:50 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: 43572@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.