GNU bug report logs - #456
menu-bar does not resize window

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-6.5 required=4.0 tests=AWL,BAYES_00,FOURLA,
	HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
Received: (at 456) by emacsbugs.donarmstrong.com; 22 Jun 2008 08:30:06 +0000
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id m5M8U1MT018844
	for <456 <at> emacsbugs.donarmstrong.com>; Sun, 22 Jun 2008 01:30:03 -0700
Received: (qmail invoked by alias); 22 Jun 2008 08:29:55 -0000
Received: from 62-47-55-177.adsl.highway.telekom.at (EHLO [62.47.55.177]) [62.47.55.177]
  by mail.gmx.net (mp026) with SMTP; 22 Jun 2008 10:29:55 +0200
X-Authenticated: #14592706
X-Provags-ID: V01U2FsdGVkX19m2LVnfulm/Pt12QNpZ31VZNXO82WDmgJFleS3uh
	AiefHgTlRAzbn5
Message-ID: <485E0D2D.2060009 <at> gmx.at>
Date: Sun, 22 Jun 2008 10:28:29 +0200
From: martin rudalics <rudalics <at> gmx.at>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: Drew Adams <drew.adams <at> oracle.com>
CC: 456 <at> debbugs.gnu.org, "'David Trallero'" <ditiem <at> gmail.com>
Subject: Re: bug#456: menu-bar does not resize window
References: <4be34f530806202238w17121692g4b598cc8f0402333 <at> mail.gmail.com>	<485CB10E.1050307 <at> gmx.at><4be34f530806210224w747c13eam7137dd6fe3e5b618 <at> mail.gmail.com> <485CF670.3010602 <at> gmx.at> <004101c8d3b4$cf446840$0200a8c0 <at> us.oracle.com>
In-Reply-To: <004101c8d3b4$cf446840$0200a8c0 <at> us.oracle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0

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

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER,
	MURPHY_DRUGS_REL8 autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
Received: (at 456) by emacsbugs.donarmstrong.com; 21 Jun 2008 19:44:31 +0000
Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5LJiOQ7024836
	for <456 <at> emacsbugs.donarmstrong.com>; Sat, 21 Jun 2008 12:44:26 -0700
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvAEAFj3XEjO+KWv/2dsb2JhbACBW6xW
X-IronPort-AV: E=Sophos;i="4.27,684,1204520400"; 
   d="scan'208";a="23056982"
Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238])
  by ironport2-out.teksavvy.com with ESMTP; 21 Jun 2008 15:44:18 -0400
Received: from pastel.home ([206.248.165.175])
        by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id BZN08619;
        Sat, 21 Jun 2008 15:44:19 -0400
Received: by pastel.home (Postfix, from userid 20848)
	id 906A47F05; Sat, 21 Jun 2008 15:44:18 -0400 (EDT)
From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 456 <at> debbugs.gnu.org, "'martin rudalics'" <rudalics <at> gmx.at>,
        "'David Trallero'" <ditiem <at> gmail.com>
Subject: Re: bug#456: menu-bar does not resize window
Message-ID: <jwvskv61spp.fsf-monnier+emacsbugreports <at> gnu.org>
References: <4be34f530806202238w17121692g4b598cc8f0402333 <at> mail.gmail.com>
	<485CB10E.1050307 <at> gmx.at>
	<4be34f530806210224w747c13eam7137dd6fe3e5b618 <at> mail.gmail.com>
	<485CF670.3010602 <at> gmx.at>
	<004101c8d3b4$cf446840$0200a8c0 <at> us.oracle.com>
Date: Sat, 21 Jun 2008 15:44:18 -0400
In-Reply-To: <004101c8d3b4$cf446840$0200a8c0 <at> us.oracle.com> (Drew Adams's
	message of "Sat, 21 Jun 2008 08:38:09 -0700")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

> 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

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-7.0 required=4.0 tests=AWL,BAYES_00,FOURLA,
	HAS_BUG_NUMBER,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham
	version=3.2.3-bugs.debian.org_2005_01_02
Received: (at 456) by emacsbugs.donarmstrong.com; 21 Jun 2008 15:39:40 +0000
Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5LFdYtp029335
	for <456 <at> emacsbugs.donarmstrong.com>; Sat, 21 Jun 2008 08:39:35 -0700
Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212])
	by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m5LFdNmK021424;
	Sat, 21 Jun 2008 09:39:23 -0600
Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151])
	by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m5LFZK8u031762;
	Sat, 21 Jun 2008 09:39:23 -0600
Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com
	with ESMTP id 3697384991214062687; Sat, 21 Jun 2008 08:38:07 -0700
Received: from dradamslap1 (/24.5.171.3)
	by default (Oracle Beehive Gateway v4.0)
	with ESMTP ; Sat, 21 Jun 2008 08:38:07 -0700
From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>, <456 <at> debbugs.gnu.org>,
        "'David Trallero'" <ditiem <at> gmail.com>
References: <4be34f530806202238w17121692g4b598cc8f0402333 <at> mail.gmail.com>	<485CB10E.1050307 <at> gmx.at><4be34f530806210224w747c13eam7137dd6fe3e5b618 <at> mail.gmail.com> <485CF670.3010602 <at> gmx.at>
Subject: RE: bug#456: menu-bar does not resize window
Date: Sat, 21 Jun 2008 08:38:09 -0700
Message-ID: <004101c8d3b4$cf446840$0200a8c0 <at> us.oracle.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <485CF670.3010602 <at> gmx.at>
Thread-Index: AcjToQqI1oIQIio3RCSnKQTklWdESwACZmPA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Brightmail-Tracker: AAAAAQAAAAI=
X-Whitelist: TRUE
X-Whitelist: TRUE

>  >>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://debbugs.gnu.org/cgi/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".

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-6.5 required=4.0 tests=AWL,BAYES_00,FOURLA,
	HAS_BUG_NUMBER autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
Received: (at 456) by emacsbugs.donarmstrong.com; 21 Jun 2008 12:40:56 +0000
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id m5LCekq3018157
	for <456 <at> emacsbugs.donarmstrong.com>; Sat, 21 Jun 2008 05:40:48 -0700
Received: (qmail invoked by alias); 21 Jun 2008 12:40:40 -0000
Received: from 62-47-60-33.adsl.highway.telekom.at (EHLO [62.47.60.33]) [62.47.60.33]
  by mail.gmx.net (mp068) with SMTP; 21 Jun 2008 14:40:40 +0200
X-Authenticated: #14592706
X-Provags-ID: V01U2FsdGVkX1+hBWQXR4OhlbSyAz/i2N3216cPfrhco+R0HEJdZX
	VXgYV4/iA8Y6lD
Message-ID: <485CF670.3010602 <at> gmx.at>
Date: Sat, 21 Jun 2008 14:39:12 +0200
From: martin rudalics <rudalics <at> gmx.at>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: David Trallero <ditiem <at> gmail.com>
CC: 456 <at> debbugs.gnu.org
Subject: Re: bug#456: menu-bar does not resize window
References: <4be34f530806202238w17121692g4b598cc8f0402333 <at> mail.gmail.com>	 <485CB10E.1050307 <at> gmx.at> <4be34f530806210224w747c13eam7137dd6fe3e5b618 <at> mail.gmail.com>
In-Reply-To: <4be34f530806210224w747c13eam7137dd6fe3e5b618 <at> mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0

 >>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://debbugs.gnu.org/cgi/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

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-6.0 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER
	autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
Received: (at 456) by emacsbugs.donarmstrong.com; 21 Jun 2008 09:24:30 +0000
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5L9OR5R001381
	for <456 <at> emacsbugs.donarmstrong.com>; Sat, 21 Jun 2008 02:24:28 -0700
Received: by rv-out-0506.google.com with SMTP id k40so6038733rvb.1
        for <456 <at> emacsbugs.donarmstrong.com>; Sat, 21 Jun 2008 02:24:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:cc:in-reply-to:mime-version:content-type
         :content-transfer-encoding:content-disposition:references;
        bh=cUstGWNe1wYIKAU+C8s59IFgTGdHjKPs80WiueivyzE=;
        b=rBhBDN8vT4+qcD+TjN3vXWglRKdBJxQ93E7FAJI7OTPEQbR9olglACzgcGRxbzaKo5
         QSU2DOwYb3wyjFdRQjith54NqsO1Svz39Bo5NI9jlUev5gZ3G50XIj2clXuXtzAoZ3mE
         fF4t2BRKENwNMvHPi/h4r2vpoacyV2QfgyFbc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=LF75OxBMk50Ep8qv0LG2NU24zhdKJgpHKop0S26c9nKxpL9hbqxnwkdxt87XctHiAy
         2ELzDWCRsUFJKCNnfoaSCdZNlbnZgE+Oa7ywRkS1c38c91Ija+Z677LFQxBGTBSBbEY1
         vUnMuWxAmbDGMID6p1SYxOBko8o3cIOtFiZB0=
Received: by 10.141.203.7 with SMTP id f7mr9020398rvq.7.1214040265859;
        Sat, 21 Jun 2008 02:24:25 -0700 (PDT)
Received: by 10.141.41.6 with HTTP; Sat, 21 Jun 2008 02:24:25 -0700 (PDT)
Message-ID: <4be34f530806210224w747c13eam7137dd6fe3e5b618 <at> mail.gmail.com>
Date: Sat, 21 Jun 2008 11:24:25 +0200
From: "David Trallero" <ditiem <at> gmail.com>
To: "martin rudalics" <rudalics <at> gmx.at>
Subject: Re: bug#456: menu-bar does not resize window
Cc: 456 <at> debbugs.gnu.org
In-Reply-To: <485CB10E.1050307 <at> gmx.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4be34f530806202238w17121692g4b598cc8f0402333 <at> mail.gmail.com>
	 <485CB10E.1050307 <at> gmx.at>

> 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

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-7.0 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
Received: (at submit) by emacsbugs.donarmstrong.com; 21 Jun 2008 08:10:14 +0000
Received: from lists.gnu.org (lists.gnu.org [199.232.76.165])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5L8AA4P016162
	for <submit <at> emacsbugs.donarmstrong.com>; Sat, 21 Jun 2008 01:10:12 -0700
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1K9yAk-0002Od-CJ
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 04:10:10 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1K9yAi-0002O6-W5
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 04:10:09 -0400
Received: from [199.232.76.173] (port=36049 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43)
	id 1K9yAi-0002O3-LD
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 04:10:08 -0400
Received: from mail.gmx.net ([213.165.64.20]:58746)
	by monty-python.gnu.org with smtp (Exim 4.60)
	(envelope-from <rudalics <at> gmx.at>)
	id 1K9yAi-0001jU-2h
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 04:10:08 -0400
Received: (qmail invoked by alias); 21 Jun 2008 07:43:26 -0000
Received: from 62-47-34-83.adsl.highway.telekom.at (EHLO [62.47.34.83]) [62.47.34.83]
  by mail.gmx.net (mp068) with SMTP; 21 Jun 2008 09:43:26 +0200
X-Authenticated: #14592706
X-Provags-ID: V01U2FsdGVkX19FoiUKFWpFXkK7Nuxjqoy24mWW7EVRQJoeUfw/iA
	ea6ZT1ETmJNgL7
Message-ID: <485CB10E.1050307 <at> gmx.at>
Date: Sat, 21 Jun 2008 09:43:10 +0200
From: martin rudalics <rudalics <at> gmx.at>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: David Trallero <ditiem <at> gmail.com>, 456 <at> debbugs.gnu.org
CC: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#456: menu-bar does not resize window
References: <4be34f530806202238w17121692g4b598cc8f0402333 <at> mail.gmail.com>
In-Reply-To: <4be34f530806202238w17121692g4b598cc8f0402333 <at> mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized.
X-CrossAssassin-Score: 2

 > 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

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-6.5 required=4.0 tests=AWL,BAYES_00,HAS_BUG_NUMBER
	autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
Received: (at 456) by emacsbugs.donarmstrong.com; 21 Jun 2008 07:43:36 +0000
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with SMTP id m5L7hWxp008941
	for <456 <at> emacsbugs.donarmstrong.com>; Sat, 21 Jun 2008 00:43:34 -0700
Received: (qmail invoked by alias); 21 Jun 2008 07:43:26 -0000
Received: from 62-47-34-83.adsl.highway.telekom.at (EHLO [62.47.34.83]) [62.47.34.83]
  by mail.gmx.net (mp068) with SMTP; 21 Jun 2008 09:43:26 +0200
X-Authenticated: #14592706
X-Provags-ID: V01U2FsdGVkX19FoiUKFWpFXkK7Nuxjqoy24mWW7EVRQJoeUfw/iA
	ea6ZT1ETmJNgL7
Message-ID: <485CB10E.1050307 <at> gmx.at>
Date: Sat, 21 Jun 2008 09:43:10 +0200
From: martin rudalics <rudalics <at> gmx.at>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: de-DE, de, en-us, en
MIME-Version: 1.0
To: David Trallero <ditiem <at> gmail.com>, 456 <at> debbugs.gnu.org
CC: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#456: menu-bar does not resize window
References: <4be34f530806202238w17121692g4b598cc8f0402333 <at> mail.gmail.com>
In-Reply-To: <4be34f530806202238w17121692g4b598cc8f0402333 <at> mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0

 > 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

Message received at (unknown):

Received: (at unknown) by unknown; unknown
X-Spam-Checker-Version: SpamAssassin 3.2.3-bugs.debian.org_2005_01_02
	(2007-08-08) on rzlab.ucr.edu
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 required=4.0 tests=BAYES_00,FOURLA,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.3-bugs.debian.org_2005_01_02
Received: (at submit) by emacsbugs.donarmstrong.com; 21 Jun 2008 05:39:07 +0000
Received: from lists.gnu.org (lists.gnu.org [199.232.76.165])
	by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5L5cwdY010676
	for <submit <at> emacsbugs.donarmstrong.com>; Fri, 20 Jun 2008 22:39:00 -0700
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1K9voQ-0001KO-9s
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 01:38:58 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1K9voO-0001Hy-82
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 01:38:57 -0400
Received: from [199.232.76.173] (port=52439 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43)
	id 1K9voN-0001Hb-O1
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 01:38:55 -0400
Received: from rv-out-0708.google.com ([209.85.198.250]:56402)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <ditiem <at> gmail.com>)
	id 1K9voN-0003a8-MH
	for bug-gnu-emacs <at> gnu.org; Sat, 21 Jun 2008 01:38:55 -0400
Received: by rv-out-0708.google.com with SMTP id k29so8087543rvb.6
        for <bug-gnu-emacs <at> gnu.org>; Fri, 20 Jun 2008 22:38:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:to
         :subject:mime-version:content-type:content-transfer-encoding
         :content-disposition;
        bh=OaA95Ym5FmLXOwSmKCkhhDrXn5r/hFnlUETEx442/xE=;
        b=HSZBBEDGbsFDmbZaxmbAS65NwhuLoyJRTm32U9zeB1V0yW3KaUaEoZCSbChajkK6FE
         umRm71aAKla2/mDzrPQGpuRHGVEBJsSy5xRVjqGX2c0aB45TC3XC93T6oI8J39Ol28OE
         H1FxC6INSN7qEHLT/U+ILs3sXEow5Lps3jzM8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type
         :content-transfer-encoding:content-disposition;
        b=hCdsovRilTxazEUgdZ84DC6473543LTJ5IN2/N1gJuSH65tqpEUpI4yP5cDD/da61p
         Vi1MvmWJOr7AKxfqlo3CEpGagXn1EbjYZq9YEJ+gaEu18iEs36WpZ/nfXERkvoU4xH+W
         QMGtFEnBwCRtLr0v7VCmSluMNSiZZGal1LCl8=
Received: by 10.140.174.11 with SMTP id w11mr8769826rve.17.1214026733337;
        Fri, 20 Jun 2008 22:38:53 -0700 (PDT)
Received: by 10.141.41.6 with HTTP; Fri, 20 Jun 2008 22:38:53 -0700 (PDT)
Message-ID: <4be34f530806202238w17121692g4b598cc8f0402333 <at> mail.gmail.com>
Date: Sat, 21 Jun 2008 07:38:53 +0200
From: "David Trallero" <ditiem <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: menu-bar does not resize window
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2)

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