bug#456: menu-bar does not resize window

bug#456: menu-bar does not resize window

[David Trallero]

M-x menu-bar-mode creates an awful effect on the emacs window. Lets
say that menu-bar-mode is nil, that is, menu does not appear, and we
have emacs "maximized". When activating it (M-x menu-bar-mode) the
emacs window resizes and the minibuffer is out of the screen.

The same happens on the other way around. if the window is maximized
and the menu-bar is removed, it "stops" being maximized.

In GNU Emacs 22.1.1 (i586-suse-linux-gnu, GTK+ Version 2.12.0)
 of 2007-09-22 on balada
Windowing system distributor `The X.Org Foundation', version 11.0.70199902
configured using `configure  '--with-gcc' '--with-pop'
'--without-hesiod' '--with-kerberos' '--with-kerberos5' '--with-leim'
'--with-xim' '--with-system-malloc' '--prefix=/usr'
'--infodir=/usr/share/info' '--mandir=/usr/share/man'
'--localstatedir=/var' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--with-x' '--with-sound' '--with-xpm'
'--with-jpeg' '--with-tiff' '--with-gif' '--with-png'
'--with-x-toolkit=gtk' '--x-includes=/usr/include'
'--x-libraries=/usr/lib:/usr/share/X11' '--build=i586-suse-linux-gnu'
'build_alias=i586-suse-linux-gnu' 'CC=gcc' 'CFLAGS=-O2 -march=i586
-mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -g -pipe -fno-strict-aliasing 	 -D_GNU_SOURCE 	
-Wno-pointer-sign 	 -Wno-unused-variable 	 -Wno-unused-label
-DSYSTEM_PURESIZE_EXTRA=55000 	 -DSITELOAD_PURESIZE_EXTRA=10000 '
'LDFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8
  default-enable-multibyte-characters: t

Major mode: XHTML

Minor modes in effect:
  shell-dirtrack-mode: t
  recentf-mode: t
  change-cursor-mode: t
  desktop-save-mode: t
  encoded-kbd-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<down-mouse-1> <mouse-1> <double-down-mouse-1> <double-mouse-1>
<down-mouse-1> <mouse-1> M-x m e n <tab> b <tab> m
<tab> <return> <help-echo> <down-mouse-1> <mouse-1>
<double-down-mouse-1> <double-mouse-1> <down-mouse-1>
<mouse-1> <double-down-mouse-1> <double-mouse-1> <down-mouse-1>
<mouse-1> M-x <up> <return> M-x <up> <return> <up>
<up> M-x b u g <tab> <tab> <backspace> <tab> <backspace>
<backspace> <tab> <tab> C-x o C-x o C-s b u g C-s C-s
C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s
C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-r
C-r C-s C-s C-s <left> <return>

Recent messages:
For information about the GNU Project and its goals, type C-h C-p. [2 times]
Menu-Bar mode disabled
Menu-bar mode disabled.  Use M-x menu-bar-mode to make the menu bar appear.
Menu-Bar mode enabled
Menu-Bar mode disabled
Menu-bar mode disabled.  Use M-x menu-bar-mode to make the menu bar appear.
Making completion list...
Loading help-mode...done
Making completion list...
Loading emacsbug...done

bug#456: menu-bar does not resize window

[martin rudalics]

 > M-x menu-bar-mode creates an awful effect on the emacs window. Lets
 > say that menu-bar-mode is nil, that is, menu does not appear, and we
 > have emacs "maximized". When activating it (M-x menu-bar-mode) the
 > emacs window resizes and the minibuffer is out of the screen.
 >
 > The same happens on the other way around. if the window is maximized
 > and the menu-bar is removed, it "stops" being maximized.

This happens by design.  The driving idea behind is, that the numbers of
lines for displaying buffers should remain unaltered when menu-/toolbars
are added/removed.  There were discussions about the desired behavior in
the past but no conclusion as far as I recall.

martin

bug#456: menu-bar does not resize window

[David Trallero]

> This happens by design.  The driving idea behind is, that the numbers of
> lines for displaying buffers should remain unaltered when menu-/toolbars
> are added/removed.  There were discussions about the desired behavior in
> the past but no conclusion as far as I recall.

Oops! sorry then. I do not want to re-open the topic. I personally think that
behavior is not correct because many visual non-desired effects are produced.
For example if you change to another buffer which has a bigger  "tool-bar" that
needs two lines, all text is moved up and down. Unfortunately, I do not know
the reason why emacs is "line-oriented" instead of being "window-representa-
tion independent".

Even more, I think it should be possible to overlay the menu in the
graphical mode
when the mouse pointer is "over it", after all, what you desire is to
have as much
space as possible for editing.

Thanks for the reply,

  David

bug#456: menu-bar does not resize window

[martin rudalics]

 >>This happens by design.  The driving idea behind is, that the numbers of
 >>lines for displaying buffers should remain unaltered when menu-/toolbars
 >>are added/removed.  There were discussions about the desired behavior in
 >>the past but no conclusion as far as I recall.
 >
 > Oops! sorry then. I do not want to re-open the topic.

You can't ;-)

It's still unclosed, see

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=25

 > I personally think that
 > behavior is not correct because many visual non-desired effects are produced.

ISTR bad interaction with some window managers.

 > For example if you change to another buffer which has a bigger  "tool-bar" that
 > needs two lines, all text is moved up and down.

Can you explain this in more detail?

 > Unfortunately, I do not know
 > the reason why emacs is "line-oriented" instead of being "window-representa-
 > tion independent".

Quite often you want an exact text-layout within a window.  For example,
you might want windows to display exactly 80 columns of buffer text.
Adding/removing scroll-bars shouldn't change that.  And what holds for
the width of windows should probably also hold for their height.

 > Even more, I think it should be possible to overlay the menu in the
 > graphical mode
 > when the mouse pointer is "over it", after all, what you desire is to
 > have as much
 > space as possible for editing.

I don't understand what you mean here.  Please elaborate.

martin

bug#456: menu-bar does not resize window

[Drew Adams]

>  >>This happens by design.  The driving idea behind is, that 
>  >>the numbers of lines for displaying buffers should remain
>  >>unaltered when menu-/toolbars are added/removed.  There were 
>  >>discussions about the desired behavior in
>  >>the past but no conclusion as far as I recall.

I don't agree that it happens by design, unless you mean that it happens just
because it happens and no one has fixed it yet. ;-)

AFAICT, it was agreed in the previous discussion that this bug should be fixed,
but we haven't yet found the right time to do it. Eli mentioned also that it
might be difficult to fix this (treat menu-bar like tool-bar) completely for
some platforms because of the difference between handling pixels and chars.

>  > Oops! sorry then. I do not want to re-open the topic.
> 
> You can't ;-) It's still unclosed, see
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=25
> 
>  > I personally think that behavior is not correct because
>  > many visual non-desired effects are produced.
> 
> ISTR bad interaction with some window managers.

AFAICT, people agreed that the menu-bar should be treated like the tool-bar is,
but that might be difficult to do precisely (pixel vs char) for some platforms. 

Eli mentioned that he seemed to remember that the size of the menu-bar "may not
be known to some toolkits, so resizing the text area might be tricky".

He called the current behavior a "misfeature", and lamented the fact that this
hadn't yet been fixed after several years (+ two more years now). The reason he
gave for not fixing it, however, was just that fixing it then would have been
ill-timed, so close to the release, especially on top of other display-related
changes at that time.

>  > For example if you change to another buffer which has a 
>  > bigger  "tool-bar" that
>  > needs two lines, all text is moved up and down.
> 
> Can you explain this in more detail?
> 
>  > Unfortunately, I do not know the reason why emacs is
>  > "line-oriented" instead of being "window-representa-
>  > tion independent".
> 
> Quite often you want an exact text-layout within a window.  
> For example, you might want windows to display exactly 80
> columns of buffer text.
> Adding/removing scroll-bars shouldn't change that.  And what holds for
> the width of windows should probably also hold for their height.

That might be one use case, for some people. If so, it is also an argument
against the current way of handling the tool-bar. You can't have it both ways.

If there are such use cases, then we should let users decide the behavior using
a user option. I and some others clearly have a different use case from that and
prefer that the frame size be left alone - for menu-bar (bugged) as well as
tool-bar (OK).

We seem somehow to have wandered from "Yes, we'd all like to fix this but that
would be difficult right now" to "No, it's the way it is by design, because some
people want the number of displayed lines to remain constant."

Let's be honest: This has been flagged as a bug that should be fixed for a long
time. The current behavior obviously does not suit at least some people. David's
example of the frame being resized larger than "maximum" so the minibuffer
disappears is one more testimonial.

If someone can fix this bug, then we should fix it. If some people actually
prefer the bugged behavior, then we can create a user option so that users can
decide for themselves. But let's not use the fact that some people might prefer
the bugged behavior as a rationale not to fix the bug.

And if this bug is just too difficult to fix - for whatever reason, then let's
note that clearly, with the precise reasons, so revisionist history doesn't pop
up from time to time.

FWIW, the emacs-devel thread referring to this (there are apparently other,
older threads also) in 2006-06 and 2007-07 is: "frame parameter menu-bar-lines
changes height of frame".

bug#456: menu-bar does not resize window

[Stefan Monnier]

> I don't agree that it happens by design, unless you mean that it happens just
> because it happens and no one has fixed it yet. ;-)

Yes, it might have been considered a good idea at some point (probably
when the issue was mixed up with the question of whether an
"emacs --geometry 80x25" frame should have the same pixel size with
menu-bar as without), but it now considered a misfeature.

So patches welcome.  Problem is: it appears that it requires a lot
of changes.


        Stefan

bug#456: menu-bar does not resize window

[martin rudalics]

 > I don't agree that it happens by design, unless you mean that it happens just
 > because it happens and no one has fixed it yet. ;-)

No.  It happens because it _was_ designed that way.

 >>Quite often you want an exact text-layout within a window.
 >>For example, you might want windows to display exactly 80
 >>columns of buffer text.
 >>Adding/removing scroll-bars shouldn't change that.  And what holds for
 >>the width of windows should probably also hold for their height.
 >
 > That might be one use case, for some people. If so, it is also an argument
 > against the current way of handling the tool-bar. You can't have it both ways.

Adding/removing tool-bars _may_ change the height of the frame on some
platforms.  I was told by Richard

   I think that change causes another bug.  The height in lines of an
   Emacs frame is not supposed to include the tool bar.  If you create a
   frame and specify 40 lines, you should get 40 lines of text, plus a
   tool bar.

[http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01148.html]

and by Robert

   I like it that the number of lines of text stays the same.

[http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01172.html]

Hence, unless we reach a common opinion on how to handle these issues
accross _all_ platforms and window managers, hardly anyone will try to
fix them (IIUC Jan gave up already).

bug#456: menu-bar does not resize window

[martin rudalics]

 > M-x menu-bar-mode creates an awful effect on the emacs window. Lets
 > say that menu-bar-mode is nil, that is, menu does not appear, and we
 > have emacs "maximized". When activating it (M-x menu-bar-mode) the
 > emacs window resizes and the minibuffer is out of the screen.
 >
 > The same happens on the other way around. if the window is maximized
 > and the menu-bar is removed, it "stops" being maximized.

This should work with current trunk as intended.  Bug closed.

Thanks, martin