GNU bug report logs - #12419
Mouse click changes layout

Previous Next

Package: emacs;

Reported by: occitan <at> esperanto.org

Date: Tue, 11 Sep 2012 22:06:01 UTC

Severity: normal

Tags: moreinfo

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #92 received at 12419 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: occitan <at> esperanto.org, 12419 <at> debbugs.gnu.org
Subject: Re: 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




This bug report was last modified 4 years and 223 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.