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

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

bug#12419: Mouse click changes layout


From: martin rudalics
Subject: bug#12419: Mouse click changes layout
Date: Sat, 15 Sep 2012 14:44:53 +0200

>> Where do you see that?  Can you give an example?
>
> Try the recipe I showed earlier in this thread with Emacs 23.3, but
> use 1000 instead of 380, and you will see that only the last part of
> the echo-area message is shown.

max-mini-window-height is a variable defined in `xdisp.c'.
Its value is 0.25

Documentation:
Maximum height for resizing mini-windows (the minibuffer and the echo area).
If a float, it specifies a fraction of the mini-window frame's height.
If an integer, it specifies a number of lines.

You can customize this variable.

This variable was introduced, or its default value was changed, in
version 23.1 of Emacs.

>> Then put a one-line window at the bottom of your frame and resize the
>> minibuffer.  At the time it sizes back the one-line window has grown.
>
> OK, but why is that a problem grave enough to be concerned about?
> Using Ediff in such a way is non-standard, so won't be a problem for
> most users.  And even in this configuration, what is so bad about
> this?

From the number of code lines he spent to handle this problem, I
conclude that it was bad enough for Gerd.

>>  > If the lowest window is large enough, why not show more of
>>  > the echo-area message, instead of always showing only the last N lines?
>>
>> I don't understand you.  As far as minibuffer resizing is concerned, you
>> can show any number of lines in the minibuffer as long as you don't try
>> to delete other windows.  So the N lines restriction you see must come
>> from somewhere else.
>
> Maybe it does, but I tried that with "emacs -Q", so the number of such
> other places is severely limited ;-)

It is.

> AFAICS, with your patch the minibuffer is never resized to show more
> than 9 lines, with the default size of the frame which can show 33
> text lines.  This is so even if I do _not_ split the frame into 2
> windows, one below the other, but instead invoke 'message' from the
> original window configuration displayed by "emacs -Q", where there's a
> single window showing the "*scratch*" buffer.  Try this:
>
>   emacs -Q
>   (message (make-string 1000 ?a))
>   C-x C-e
>
> How many lines and how many a's do you see in the echo area?

9 lines - so our Emacsen are created equal.  Nothing can beat evolution ;-)

martin





reply via email to

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