bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43572: Feature request: make it possible to choose whether the first


From: Gregory Heytings
Subject: bug#43572: Feature request: make it possible to choose whether the first lines of the minibuffer should be displayed instead of the last ones
Date: Fri, 25 Sep 2020 08:34:50 +0000
User-agent: Alpine 2.22 (NEB 394 2020-01-19)


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 via email to

[Prev in Thread] Current Thread [Next in Thread]