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

[Gregory Heytings via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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