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