frame parameter menu-bar-lines changes height of frame

frame parameter menu-bar-lines changes height of frame

[Drew Adams]

Can we please revisit this now that the release is out?

> From: Drew Adams Sent: Saturday, June 10, 2006 8:57 AM
> To: Emacs-Pretest-Bug
> Subject: frame parameter menu-bar-lines changes height of frame
>
> emacs -Q
>
> (make-frame '((width . 70)(height . 50)))
> (modify-frame-parameters (selected-frame) '((menu-bar-lines . 0)))
> (frame-parameters)
> (modify-frame-parameters (selected-frame) '((menu-bar-lines . 1)))
> (frame-parameters)
>
> Adding and removing a menu-bar line changes the visible height of the
> frame (incorrect), but it does not change the `height' frame
> parameter. The correct behavior is that observed for `tool-bar-lines':
> neither the visible frame height nor the `height' parameter is
> changed.

Use (assq 'height (frame-parameters)) to see that the `height'
parameter does not change.

This was first reported 2.5 years ago. Here is the last bit
of discussion about it:

> From: Drew Adams Sent: Tuesday, June 13, 2006 11:59 AM
> Hi Eli,
> Thanks for your explanation. I understand better now.
>
> I'm fine with this not being fixed before the release. I would
> ask that it be fixed soon thereafter, if possible.
>
> If necessary, we can reopen the discussion of what the behavior
> should be. To me, it should be like the tool-bar behavior. If
> that's not possible in some contexts, then those contexts can be
> treated specially (do the best we can to determine menu-bar height etc.).
>
> Showing and hiding the menu-bar should not change the frame size
> whenever that is avoidable. There is no reason to reduce
> everything to the lowest common denominator, if that denominator
> is bugged behavior. If the bugged behavior is sometimes
> unavoidable, so be it, but let's not use it as the norm.
>
> Thx - Drew
>
> -----------------
>
>     > You've said that the reason to not fix this now or soon is
>     that fixing it
>     > would be difficult. Could you explain why menu-bar-lines is
>     different from
>     > tool-bar-lines in this respect?
>
>     Because, historically, the menu bar was just a line of text at the
>     upper edge of the frame (and still is, in the non-toolkit and tty
>     builds).  Tool bar was never an integral number of text lines.
>
>     > The latter works correctly. Couldn't the tool-bar-lines
>     > implementation (fix) apply also to menu-bar-lines?
>
>     Theoretically, yes.  But even the thread you cited (which started
>     about a different issue, and only touched the menu bar tangentially)
>     reveals that people are divided on what should be the right behavior.
>     There are also other complications, IIRC: the size of the menu bar may
>     not be known with some toolkits, so resizing the text area might be
>     tricky.
>
>     That is why I don't think we should try to fix this now.  The fact
>     that two years have passed (actually much more, since this issue was
>     discussed back when Gerd Moellmann was the head maintainer) is
>     unfortunate, but I think we will shoot in our foot if we add now as
>     yet additional complication in the display-related code.  I fear the
>     redisplay-dont-pause changes already complicated things enough, and
>     might prolong the pretest.  Emacs had this misfeature for a long time,
>     and complaints, if there were any, were minimal.  I think the fix can
>     wait a little longer.


In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
 of 2007-06-02 on RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/include'

RE: bug#25: Acknowledgement (frame parameter menu-bar-lines changes height of frame)

[Drew Adams]

Uh, why are we getting such emails?

And why does it say to submit further info about the bug to
"25@emacsbugs.donarmstrong.com, as before." As before?

We should be able to keep the same thread as the original bug-report mail,
and reply to that, _as before_. Same thread, subject line, reply-to, etc. We
should continue to be able to sort mails by thread, sender, etc. in our mail
clients, and not have a thread get split into different subjects, addresses,
etc.

Also, there is no inclusion of the original bug report, and no mention of
the date it was filed (10 months ago, in this case - so much for "Thank you
for filing a new bug report"). Instead, there is a URL to a Web site - not
equivalent.

This is not an improvement for users, IMO. Please keep email about a bug
within a single thread. If you want to also mirror part of that thread
invisibly to some bug-report backend, then do so, but please don't confuse
users this way.

Thx.

> -----Original Message-----
> From: Emacs bug Tracking System [mailto:don@donarmstrong.com] 
> Sent: Friday, February 29, 2008 1:15 AM
> To: Drew Adams
> Subject: bug#25: Acknowledgement (frame parameter 
> menu-bar-lines changes height of frame)
> 
> 
> Thank you for filing a new bug report with Emacs.
> 
> This is an automatically generated reply to let you know your message
> has been received.
> 
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  Emacs Bugs <emacsbugs@lists.donarmstrong.com>
> 
> If you wish to submit further information on this problem, please
> send it to 25@emacsbugs.donarmstrong.com, as before.
> 
> Please do not send mail to don@donarmstrong.com unless you wish
> to report a problem with the Bug-tracking system.
> 
> 
> -- 
> 25: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=25
> Emacs Bug Tracking System
> Contact don@donarmstrong.com with problems
> 

Re: bug#25: Acknowledgement (frame parameter menu-bar-lines changes height of frame)

[Jason Rumney]

Drew Adams wrote:
> Uh, why are we getting such emails?
>   

You are getting this because I picked one of your outstanding reports to 
test the bug submission process. I didn't realise that it would result 
in an auto-reply to you, next time I will forward an email from my own 
address rather than resending an existing report with original headers 
intact.

> And why does it say to submit further info about the bug to
> "25@emacsbugs.donarmstrong.com, as before." As before?
>   

Obviously there are problems to be ironed out.

>  We should continue to be able to sort mails by thread, sender, etc. in our mail
> clients, and not have a thread get split into different subjects, addresses,
> etc.
>   

I think we're going to have to put up with some breakage of this ideal 
while we make the transition to the new bug reporting system. Once the 
new system is up and running, the prefixes on the subject line should be 
consistent once the bug has hit the system. If we impose requirements 
like "no changing the subject line" on bug reporting tools, we are going 
to end up with a bug tracker that is basically an unsorted mailing list 
archive that someone needs to go in and fix up by hand.

RE: bug#25: Acknowledgement (frame parameter menu-bar-lines changes height of frame)

[Drew Adams]

> > Uh, why are we getting such emails?
> 
> You are getting this because I picked one of your outstanding 
> reports to test the bug submission process. I didn't realise
> that it would result in an auto-reply to you, next time I
> will forward an email from my own address rather than
> resending an existing report with original headers intact.

OK. No problem. Thanks for the prompt explanation.

> > And why does it say to submit further info about the bug to
> > "25@emacsbugs.donarmstrong.com, as before." As before?
> 
> Obviously there are problems to be ironed out.

HTH.

> >  We should continue to be able to sort mails by thread, 
> > sender, etc. in our mail clients, and not have a thread
> > get split into different subjects, addresses, etc.
> 
> I think we're going to have to put up with some breakage of 
> this ideal while we make the transition to the new bug
> reporting system.

OK (for the transition).

> Once the new system is up and running, the prefixes on the
> subject line should be consistent once the bug has hit the
> system.

Consistent is good. Even better is to treat it as a normal mail thread, so
the original message is also in the same stream. IOW, bug sending should
also have the same prefix, whatever it is.

> If we impose requirements like "no changing the subject line"
> on bug reporting tools, we are going to end up with a bug
> tracker that is basically an unsorted mailing list 
> archive that someone needs to go in and fix up by hand.

I don't see why. Why would an automatic system not be able to keep the
subject intact (using whatever prefixing convention it wants, consistently).

I use bug trackers everyday, as I'm sure others do also. I have no problem
with a Web-based system, with or without initial reporting by email. But
there should be one-stop shopping for the complete bug-report history:
everything should be in one thread - either email or on a Web page, and that
one place should also be where you post updates. It should be easy to sort
and search bug reports in different ways. This is nothing new, in general.

Re: bug#25: Acknowledgement (frame parameter menu-bar-lines changes height of frame)

[Don Armstrong]

On Fri, 29 Feb 2008, Drew Adams wrote:
> We should be able to keep the same thread as the original bug-report
> mail, and reply to that, _as before_. Same thread, subject line,
> reply-to, etc. We should continue to be able to sort mails by
> thread, sender, etc. in our mail clients, and not have a thread get
> split into different subjects, addresses, etc.

Assuming the emacs developers decide to use debbugs, each bug has it's
own list, and you'll send more information to
bugnum@emacsbugs.donarmstrong.com[1] so thread sorting etc. will all
happen as you're expecting it to, assuming References: and
In-Reply-To: are kept intact by correspondents.

> Also, there is no inclusion of the original bug report, and no
> mention of the date it was filed (10 months ago, in this case - so
> much for "Thank you for filing a new bug report"). Instead, there is
> a URL to a Web site - not equivalent.

When everything is working normally, you will get such an ack within
minutes of filing a new report (so sending you back the original bug
report wouldn't really be useful.)


Don Armstrong

1: Well, obviously not to my machine, but some equivalent address.
-- 
A Democracy lead by politicians and political parties, fails.

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: bug#25: Acknowledgement (frame parameter menu-bar-lines changes height of frame)

[Don Armstrong]

On Fri, 29 Feb 2008, Drew Adams wrote:
> Consistent is good. Even better is to treat it as a normal mail
> thread, so the original message is also in the same stream. IOW, bug
> sending should also have the same prefix, whatever it is.

It is a normal mail thread, actually. You received the
acknowledgement, which is outside the thread. Maintainers and everyone
else following the thread just receive a normal method with bug#
prepended to the subject.
 
> I don't see why. Why would an automatic system not be able to keep
> the subject intact (using whatever prefixing convention it wants,
> consistently).

It does do this, actually.

> But there should be one-stop shopping for the complete bug-report
> history: everything should be in one thread - either email or on a
> Web page, and that one place should also be where you post updates.

And this is the case as well. bugnum@btssystem is the place where you
mail followups, and anyone who has elected to receive followups gets
them as well. What you got (and anyone else who sends mail to the
system without headers to say that you don't want them gets) is an
acknowledgement that your followup was received. [If you don't want
them, add an X-Debbugs-No-Ack: header or psuedoheader.]


Don Armstrong

-- 
It was said that life was cheap in Ankh-Morpork. This was, of course,
completely wrong. Life was often very expensive; you could get death
for free.
 -- Terry Pratchet _Pyramids_ p25

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: bug#25: Acknowledgement (frame parameter menu-bar-lines changes height of frame)

[Stefan Monnier]

> Uh, why are we getting such emails?
> And why does it say to submit further info about the bug to
> "25@emacsbugs.donarmstrong.com, as before."

This email address is how the bug-tracking system keep track of threads
(instead of using "References:" and "In-Reply-To:").

> We should be able to keep the same thread as the original bug-report mail,
> and reply to that, _as before_.

In what way can't you?  You mean because you now have the bug-gnu-emacs
tread and the 25@emacsbugs.donarmstrong.com thread?  If so, it's
a temporary problem which will be sorted out soon by removing the
bug-gnu-emacs (and ultimately sending the new thread to the
bug-gnu-emacs recipients).


        Stefan

Re: bug#25: Acknowledgement (frame parameter menu-bar-lines changes height of frame)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 02 Mar 2008 00:29:39 -0500
> Cc: 25@emacsbugs.donarmstrong.com, emacs-devel@gnu.org
> 
> > Uh, why are we getting such emails?
> > And why does it say to submit further info about the bug to
> > "25@emacsbugs.donarmstrong.com, as before."
> 
> This email address is how the bug-tracking system keep track of threads
> (instead of using "References:" and "In-Reply-To:").
> 
> > We should be able to keep the same thread as the original bug-report mail,
> > and reply to that, _as before_.
> 
> In what way can't you?  You mean because you now have the bug-gnu-emacs
> tread and the 25@emacsbugs.donarmstrong.com thread?  If so, it's
> a temporary problem which will be sorted out soon by removing the
> bug-gnu-emacs (and ultimately sending the new thread to the
> bug-gnu-emacs recipients).

I'm confused: in another message you said to subscribe to
emacsbugs.donarmstrong.com, but now you seem to be saying that the bug
reports will be sent to recipients of bug-gnu-emacs?  If the latter is
correct, why should we subscribe to emacsbugs.donarmstrong.com?

Re: bug#25: Acknowledgement (frame parameter menu-bar-lines changes height of frame)

[Don Armstrong]

On Sun, 02 Mar 2008, Eli Zaretskii wrote:
> I'm confused: in another message you said to subscribe to
> emacsbugs.donarmstrong.com, but now you seem to be saying that the
> bug reports will be sent to recipients of bug-gnu-emacs? If the
> latter is correct, why should we subscribe to
> emacsbugs.donarmstrong.com?

emacsbugs@lists.donarmstrong.com is what the maintainer of the emacs
package is configured as, and the mailing list that receives all of
the mails that a maintainer would see. You should subscribe to it, if,
during this teseting period you want to see exactly the types of
messages that the maintainers would see.

When we actually deploy, my suggestion is that bug-gnu-emacs be
configured to send messages to submit@emacsbugs.gnu.org (or wherever
the debbugs install ends up) and current subscribers of the
bug-gnu-emacs list get stuck on a new mailing list where all bug
related e-mails are copied. [The equivalent for Debian is
debian-bugs-dist@lists.debian.org[1]] (An alternative equivalent would
be to keep the bug-gnu-emacs list, but have incomming mail not sent
from the debbugs install redirected to submit@emacsbugs.gnu.org.[2])

Each of the configured packages will presumably also have their own
mailing list which people can subscribe to if they aren't interested
in all emacs related bugs. [We also have hooks for EoC to allow for
subscription to single bugs if that's desired.]


Don Armstrong

1: This mailing list averages a few thousand messages a day.
2: I'm too used to smartlist which makes this sort of thing trivial;
no clue how to do it in mailman.
-- 
A citizen of America will cross the ocean to fight for democracy, but
won't cross the street to vote in a national election.
 -- Bill Vaughan

http://www.donarmstrong.com              http://rzlab.ucr.edu

bug#25: frame parameter menu-bar-lines changes height of frame

[Stefan Monnier]

severity 25 wishlist
thanks

The menu-bar currently isn't counted as part of the "text area" (whose
size is described by the height and width frame parameters), whereas the
tool-bar is.

I agree that the way the toolbar behaves in this respect is preferable,
but because Emacs still counts sizes in multiple of lines and columns,
it also has drawbacks (typically a few pixels wasted between the
tool-bar and the actual text).

Hopefully, we'll fix this at some point.

bug#25: frame parameter menu-bar-lines changes height of frame

[Drew Adams]

Too bad. Apparently people have been agreeing that this should be fixed since it
was first discussed when Gerd was in charge - years.

Previously, the reason given for not fixing it at the time was that the release
was imminent and we didn't want to risk the change.

Now, this has simply been downgraded to "wishlist" - poof!  Dommage.

> From: Stefan Monnier Sent: Tuesday, June 10, 2008 12:07 PM
> severity 25 wishlist
> thanks
> 
> The menu-bar currently isn't counted as part of the "text area" (whose
> size is described by the height and width frame parameters), 
> whereas the tool-bar is.
> 
> I agree that the way the toolbar behaves in this respect is 
> preferable,
> but because Emacs still counts sizes in multiple of lines and columns,
> it also has drawbacks (typically a few pixels wasted between the
> tool-bar and the actual text).
> 
> Hopefully, we'll fix this at some point.

Re: bug#25: frame parameter menu-bar-lines changes height of frame

[Jason Rumney]

Drew Adams wrote:
> Now, this has simply been downgraded to "wishlist" - poof!  Dommage.
>   

It is not a downgrade, it is a categorization.

RE: bug#25: frame parameter menu-bar-lines changes height of frame

[Drew Adams]

> > Now, this has simply been downgraded to "wishlist" - poof!  Dommage.
> 
> It is not a downgrade, it is a categorization.

Strictly speaking, since this is the first time it has been categorized (the
categories are new), you are correct.

However, relative to what was discussed about this in the past, it is a
downgrade, IMO. It was not previously characterized as "wishlist", but as
something that should be done after the imminent release.

Re: bug#25: frame parameter menu-bar-lines changes height of frame

[Stefan Monnier]

>> > Now, this has simply been downgraded to "wishlist" - poof!  Dommage.
>> It is not a downgrade, it is a categorization.
> Strictly speaking, since this is the first time it has been categorized (the
> categories are new), you are correct.

> However, relative to what was discussed about this in the past, it is a
> downgrade, IMO. It was not previously characterized as "wishlist", but as
> something that should be done after the imminent release.

Yes, it's something that should be done as soon as possible.
But nobody has stepped forward to do it.  And nobody has made a case
that this is an important bug to fix.  So it's a wishlist item, waiting
for a generous soul.


        Stefan

bug#25: frame parameter menu-bar-lines changes height of frame

[martin rudalics]

 > > emacs -Q
 > >
 > > (make-frame '((width . 70)(height . 50)))
 > > (modify-frame-parameters (selected-frame) '((menu-bar-lines . 0)))
 > > (frame-parameters)
 > > (modify-frame-parameters (selected-frame) '((menu-bar-lines . 1)))
 > > (frame-parameters)
 > >
 > > Adding and removing a menu-bar line changes the visible height of the
 > > frame (incorrect), but it does not change the `height' frame
 > > parameter. The correct behavior is that observed for `tool-bar-lines':
 > > neither the visible frame height nor the `height' parameter is
 > > changed.
 >
 > Use (assq 'height (frame-parameters)) to see that the `height'
 > parameter does not change.

This can now be handled on trunk/master by adding 'menu-bar-lines' to
`frame-inhibit-implied-resize'.  Bug closed.

Thanks, martin

bug#25: frame parameter menu-bar-lines changes height of frame

[Drew Adams]

> This can now be handled on trunk/master by adding 'menu-bar-lines'
> to `frame-inhibit-implied-resize'.  Bug closed.

I don't have a version with the fix yet.  (I have been unable to use
any Emacs versions since mid-October because they break the use of
frames in various ways, but I will look into those problems and report
them as I narrow things down.)

I gather that `frame-inhibit-implied-resize' is a user option.  It's
great that users can now control the behavior, but I wonder how that
helps code and how it fixes the bug reported here.  The point of
this bug was that `menu-bar-lines' should behave like `tool-bar-lines'
does: adding or removing a menu bar, or increasing/decreasing the
number of its lines, should not change the visible frame height.

If that behavior is only optional, and decided by users, then it
sounds like things are not the same as for `tool-bar-lines' and
that code cannot depend on the behavior being the same.

Anyway, I won't judge the fix until I can check it out.  And my
guess is that it is an improvement.  Thanks for working on this,
in any case.

bug#25: frame parameter menu-bar-lines changes height of frame

[martin rudalics]

 > I gather that `frame-inhibit-implied-resize' is a user option.  It's
 > great that users can now control the behavior, but I wonder how that
 > helps code and how it fixes the bug reported here.

Please refrain from calling this a bug.  It's a behavior you dislike and
we can try to modify it in your sense.  But let's do that in a minimally
invasive fashion so other users don't get annoyed by our modifications.

 > The point of
 > this bug was that `menu-bar-lines' should behave like `tool-bar-lines'
 > does: adding or removing a menu bar, or increasing/decreasing the
 > number of its lines, should not change the visible frame height.

For graphical displays now the following hold:

If a user adds both `menu-bar-lines' and `tool-bar-lines' to
`frame-inhibit-implied-resize' or the latter is t or the frame is either
maximized or fullscreen, then toggling either `menu-bar-mode' or
`tool-bar-mode' conceptually do not change the visible frame height.

If neither `menu-bar-lines' and `tool-bar-lines' are members of
`frame-inhibit-implied-resize' and the latter is not t and the frame is
neither maximized nor fullscreen, then toggling either `menu-bar-mode'
or `tool-bar-mode' conceptually do change the visible frame height.

And this holds for Gtk just as for Windows.

 > If that behavior is only optional, and decided by users, then it
 > sounds like things are not the same as for `tool-bar-lines' and
 > that code cannot depend on the behavior being the same.

Code can always read the value of `frame-inhibit-implied-resize' as well
as the maximized/fullscreen status of a frame.

martin