Frame Height Different for Default Frame and Additional Frames

Frame Height Different for Default Frame and Additional Frames

[Rocco Pigneri]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

To whom this may concern:

 

The size of the first frame created by an Emacs 22.1 instance and the
subsequent frames created by that instance differ on Windows.  The first
frame is exactly three lines shorter than all subsequent frames.

 

Steps to reproduce:

 

1. Put the following line in your .emacs file:

 

(add-to-list 'default-frame-alist '(height . 57))

 

2. Start a new instance of Emacs.  Note the height of the frame.

 

3. Press C-x 5 2 to create a new frame.  You will notice that this new frame
is three lines longer than the old one.

 

Thank you,

 

Rocco Pigneri


[-- Attachment #2: Type: text/html, Size: 3999 bytes --]

Re: Frame Height Different for Default Frame and Additional Frames

[martin rudalics]

 > 1. Put the following line in your .emacs file:
 >
 > (add-to-list 'default-frame-alist '(height . 57))
 >
 > 2. Start a new instance of Emacs.  Note the height of the frame.
 >
 > 3. Press C-x 5 2 to create a new frame.  You will notice that this new frame
 > is three lines longer than the old one.

FWIW, the behavior you describe violates the according description in
the Elisp manual:

  -- Variable: default-frame-alist
      This is an alist specifying default values of frame parameters for
      all Emacs frames--the first frame, and subsequent frames.  When ...

You should get the desired behavior by setting

(add-to-list 'initial-frame-alist '(height . 57))

in your .emacs.  Nevertheless, I'd count this problematic.  Eli, can
this be fixed or should we add something to ~/etc/PROBLEMS ?

[Fwd: Frame Height Different for Default Frame and Additional Frames]

[martin rudalics]

> From: Rocco Pigneri <rocco@intermedinc.net>
> To: bug-gnu-emacs@gnu.org
> Subject: Frame Height Different for Default Frame and Additional Frames
> 
>  > 1. Put the following line in your .emacs file:
>  >
>  > (add-to-list 'default-frame-alist '(height . 57))
>  >
>  > 2. Start a new instance of Emacs.  Note the height of the frame.
>  >
>  > 3. Press C-x 5 2 to create a new frame.  You will notice that this new frame
>  > is three lines longer than the old one.
> 
I can confirm that behavior with Emacs -Q (EMACS_22_BASE) on Windows ME.
Is this something that can be fixed or something that should be added to
~/etc/PROBLEMS ?  Note that the behavior violates the description from
the Elisp manual

  -- Variable: default-frame-alist
      This is an alist specifying default values of frame parameters for
      all Emacs frames--the first frame, and subsequent frames.  When ...

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Richard Stallman]

    I can confirm that behavior with Emacs -Q (EMACS_22_BASE) on Windows ME.
    Is this something that can be fixed or something that should be added to
    ~/etc/PROBLEMS ?

If nobody else reports on having debugged this and tells what the
cause is, would you please debug it?

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[martin rudalics]

> If nobody else reports on having debugged this and tells what the
> cause is, would you please debug it?

The cause is the toolbar.  Since I never use it I never noticed
the bug before.

I can reproduce the bug with the single-line .emacs:

(add-to-list 'default-frame-alist '(height . 37))

I can't reproduce it with the two-liner:

(add-to-list 'default-frame-alist '(height . 37))
(tool-bar-mode nil)

I faintly recall some discussion about this on emacs-devel.
Maybe the bug has been already fixed on the trunk and people
can't reproduce it now.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Jan Djärv]

martin rudalics skrev:
>> If nobody else reports on having debugged this and tells what the
>> cause is, would you please debug it?
> 
> The cause is the toolbar.  Since I never use it I never noticed
> the bug before.
> 
> I can reproduce the bug with the single-line .emacs:
> 
> (add-to-list 'default-frame-alist '(height . 37))
> 
> I can't reproduce it with the two-liner:
> 
> (add-to-list 'default-frame-alist '(height . 37))
> (tool-bar-mode nil)
> 
> I faintly recall some discussion about this on emacs-devel.
> Maybe the bug has been already fixed on the trunk and people
> can't reproduce it now.
> 

It has not been fixed.  Further more, different toolkits/ports needs different 
fixes, so the w32 port needs its own unique fix.

	Jan D.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[martin rudalics]

 > It has not been fixed.  Further more, different toolkits/ports needs
 > different fixes, so the w32 port needs its own unique fix.

I see.  But isn't this frame size increase hardcoded in the following
section of frame.c?

   /* This used to be done _before_ calling x_figure_window_size, but
      since the height is reset here, this was really a no-op.  I
      assume that moving it here does what Gerd intended (although he
      no longer can remember what that was...  ++KFS, 2003-03-25.  */

   /* Add the tool-bar height to the initial frame height so that the
      user gets a text display area of the size he specified with -g or
      via .Xdefaults.  Later changes of the tool-bar height don't
      change the frame size.  This is done so that users can create
      tall Emacs frames without having to guess how tall the tool-bar
      will get.  */
   if (toolbar_p && FRAME_TOOL_BAR_LINES (f))
     {
       ...

       bar_height = DEFAULT_TOOL_BAR_IMAGE_HEIGHT + 2 * margin + 2 * relief;
       FRAME_LINES (f) += (bar_height + FRAME_LINE_HEIGHT (f) - 1) / FRAME_LINE_HEIGHT (f);
     }

If I understand this code correctly, it always adds some lines to the
default frame when a toolbar is present.  Apparently it fails to do so
for the initial frame on w32.  The first comment is not really an
enlightment in this regard.

Could you clarify two things: (1) How is this code related to initial
frames and default frames; does (should) it affect only the latter or
both ?  (2) Doesn't the (toolbar_p && FRAME_TOOL_BAR_LINES (f))
condition hardcode a size increase whenever a toolbar is present ?

Also, the second comment seems to indicate that the frame size should
remain constant regardless of whether a toolbar is present or not.  Is
this correct ?

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Jan Djärv]

martin rudalics skrev:
>  > It has not been fixed.  Further more, different toolkits/ports needs
>  > different fixes, so the w32 port needs its own unique fix.
> 
> I see.  But isn't this frame size increase hardcoded in the following
> section of frame.c?

I haven't seen this code before, it will not do the right thing for Gtk+ at 
least.  I think this code assumes the Emacs native tool bar.  I don't know if 
w32 uses that.


> 
>   /* This used to be done _before_ calling x_figure_window_size, but
>      since the height is reset here, this was really a no-op.  I
>      assume that moving it here does what Gerd intended (although he
>      no longer can remember what that was...  ++KFS, 2003-03-25.  */
> 
>   /* Add the tool-bar height to the initial frame height so that the
>      user gets a text display area of the size he specified with -g or
>      via .Xdefaults.  Later changes of the tool-bar height don't
>      change the frame size.  This is done so that users can create
>      tall Emacs frames without having to guess how tall the tool-bar
>      will get.  */
>   if (toolbar_p && FRAME_TOOL_BAR_LINES (f))
>     {
>       ...
> 
>       bar_height = DEFAULT_TOOL_BAR_IMAGE_HEIGHT + 2 * margin + 2 * relief;
>       FRAME_LINES (f) += (bar_height + FRAME_LINE_HEIGHT (f) - 1) / 
> FRAME_LINE_HEIGHT (f);
>     }
> 
> If I understand this code correctly, it always adds some lines to the
> default frame when a toolbar is present.  Apparently it fails to do so
> for the initial frame on w32.  The first comment is not really an
> enlightment in this regard.
> 
> Could you clarify two things: (1) How is this code related to initial
> frames and default frames; does (should) it affect only the latter or
> both ?  (2) Doesn't the (toolbar_p && FRAME_TOOL_BAR_LINES (f))
> condition hardcode a size increase whenever a toolbar is present ?

(1).  It depends on frame parameters and tool kit used. FRAME_TOOL_BAR_LINES 
is always 0 for Gtk+ which uses an external (gtk+) tool bar.  For the native 
Emacs tool bar, it is taken from the frame parameters.

(2)  Not for the external tool bar.  Then FRAME_TOOL_BAR_LINES (f) is 0.  But 
for the native Emacs tool bar, it does.


> 
> Also, the second comment seems to indicate that the frame size should
> remain constant regardless of whether a toolbar is present or not.  Is
> this correct ?

I think the purpose is that if you specify -g 80x24, you should get 24 lines 
that you can edit, with or without the tool bar.  The native tool bar confuses 
things by being specified in lines also (to help redisplay I guess).  So if 
you have a tool bar that occupies two lines and you said -g 80x24, the frame 
will actually be 26 lines high.  Or that is the intent anyway.

I think the bug is because frame parameters for the first frame is applied 
after the frame already has been created, but for frames created later, they 
are applied before the frame gets created.

	Jan D.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Jason Rumney]

Jan Djärv wrote:
> I haven't seen this code before, it will not do the right thing for
> Gtk+ at least.  I think this code assumes the Emacs native tool bar. 
> I don't know if w32 uses that.

It does.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[martin rudalics]

 > I think the bug is because frame parameters for the first frame is
 > applied after the frame already has been created, but for frames created
 > later, they are applied before the frame gets created.

IIUC the value of `tool-bar-mode' is known only after the first frame
has been created.  Hence we can either remove the adjustment code for the
native tool-bar or add an entry to PROBLEMS.  Is there a third way?

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Richard Stallman]

    I faintly recall some discussion about this on emacs-devel.
    Maybe the bug has been already fixed on the trunk and people
    can't reproduce it now.

Can you try updating the sources now and see if you can reproduce it?

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Richard Stallman]

Martin, could you try debugging this on GNU/Linux?

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Jan Djärv]

martin rudalics skrev:
>  > I think the bug is because frame parameters for the first frame is
>  > applied after the frame already has been created, but for frames created
>  > later, they are applied before the frame gets created.
> 
> IIUC the value of `tool-bar-mode' is known only after the first frame
> has been created.  Hence we can either remove the adjustment code for the
> native tool-bar or add an entry to PROBLEMS.  Is there a third way?
> 
> 

The obvious (but more difficult) would be to read all startup lisp before 
creating the first frame.  Or create an initial frame (like a splash screen), 
and then replace it with a proper "editing" frame.

What I had in mind was a modeless frame with the Gnu logo and one line of text 
from *Messages* at the borrom.  When startup is complete, then create a proper 
frame with tool bars, menus and such.  Of course there are special cases to 
handle, like debug on startup, errors in ~/.emacs and such.

Another way is to forcibly resize the frame after all startup code has been 
read and the value of `tool-bar-mode' is known.  I think Emacs used to do that 
before.  But it looks ugly.

	Jan D.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[martin rudalics]

 > Martin, could you try debugging this on GNU/Linux?

Sorry no, my GUN/Linux machine crashed a while ago.  Someone using a
non-Gtk+ install would have to do that.  It would already be helpful if
someone could post here whether the behavior occurs on a non-Gtk+ Emacs
on GNU/Linux.

To reproduce:

Create a one-line .emacs like

(add-to-list 'default-frame-alist '(height . 37))

that is, the frame height should be less than that of your screen.

Start Emacs, do C-x 5 2, and tell us whether the heights of the two
frames differ.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[martin rudalics]

 > The obvious (but more difficult) would be to read all startup lisp
 > before creating the first frame.  Or create an initial frame (like a
 > splash screen), and then replace it with a proper "editing" frame.
 >
 > What I had in mind was a modeless frame with the Gnu logo and one line of text
 > from *Messages* at the borrom.  When startup is complete, then create a proper
 > frame with tool bars, menus and such.  Of course there are special cases to
 > handle, like debug on startup, errors in ~/.emacs and such.

I wonder whether there really is a gtk+/native toolbars dichotomy here.
After all it's up to .emacs whether I want a tool-/menu-/scrollbar, what
the size of the initial frame should be ...  Hence a gtk+ initial frame
must get resized as well when .emacs turns tool-bar-mode off.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Stefan Monnier]

> The obvious (but more difficult) would be to read all startup lisp before
> creating the first frame.

It's not that difficult.  The first frame created is `terminal-frame' anyway
and this one does not need any information from .emacs.  Currently we create
a second (X11, or w32, or mac, or tty) frame and delete the `terminal-frame'
before reading the .emacs but we could do that later.


        Stefan

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Jan Djärv]

martin rudalics skrev:
>> Martin, could you try debugging this on GNU/Linux?
> 
> Sorry no, my GUN/Linux machine crashed a while ago.  Someone using a
> non-Gtk+ install would have to do that.  It would already be helpful if
> someone could post here whether the behavior occurs on a non-Gtk+ Emacs
> on GNU/Linux.
> 
> To reproduce:
> 
> Create a one-line .emacs like
> 
> (add-to-list 'default-frame-alist '(height . 37))
> 
> that is, the frame height should be less than that of your screen.
> 
> Start Emacs, do C-x 5 2, and tell us whether the heights of the two
> frames differ.

Yes they do.  It looks like default-frame-alist is ignored for the first frame.

	Jan D.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Richard Stallman]

    > The obvious (but more difficult) would be to read all startup lisp before
    > creating the first frame.

    It's not that difficult.  The first frame created is `terminal-frame' anyway
    and this one does not need any information from .emacs.  Currently we create
    a second (X11, or w32, or mac, or tty) frame and delete the `terminal-frame'
    before reading the .emacs but we could do that later.

One concern here is handling errors.  Error messages that occur before
the really intended frame is set up kill Emacs.  That is implemented
in cmd_error_internal.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Richard Stallman]

Does this bug still happen for you, or has it been fixed?

    > Create a one-line .emacs like
    > 
    > (add-to-list 'default-frame-alist '(height . 37))
    > 
    > that is, the frame height should be less than that of your screen.
    > 
    > Start Emacs, do C-x 5 2, and tell us whether the heights of the two
    > frames differ.

    Yes they do.  It looks like default-frame-alist is ignored for the first frame.

This does not fail for me.  When I start Emacs with just

    (add-to-list 'default-frame-alist '(height . 15))

in .emacs, it makes a 15-line frame.  I tested that in Emacs 22
and in the trunk, and it makes a 15-line frame in both.
(The frame starts out the default size and then shrinks, of course.)

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[martin rudalics]

 > Does this bug still happen for you, or has it been fixed?
 >
 >     > Create a one-line .emacs like
 >     >
 >     > (add-to-list 'default-frame-alist '(height . 37))
 >     >
 >     > that is, the frame height should be less than that of your screen.
 >     >
 >     > Start Emacs, do C-x 5 2, and tell us whether the heights of the two
 >     > frames differ.
 >
 >     Yes they do.  It looks like default-frame-alist is ignored for the first frame.
 >
 > This does not fail for me.  When I start Emacs with just
 >
 >     (add-to-list 'default-frame-alist '(height . 15))
 >
 > in .emacs, it makes a 15-line frame.  I tested that in Emacs 22
 > and in the trunk, and it makes a 15-line frame in both.
 > (The frame starts out the default size and then shrinks, of course.)

The size of the initial frame seems correct because initial frames get
the same height regardless of whether they have a tool-bar or not (if
they didn't we'd probably have another bug).  Hence, I conclude that
additional frames created _after_ the initial frame are too high.
Commenting out the following stretch from frame.c fixes the bug for me.

   /* This used to be done _before_ calling x_figure_window_size, but
      since the height is reset here, this was really a no-op.  I
      assume that moving it here does what Gerd intended (although he
      no longer can remember what that was...  ++KFS, 2003-03-25.  */

   /* Add the tool-bar height to the initial frame height so that the
      user gets a text display area of the size he specified with -g or
      via .Xdefaults.  Later changes of the tool-bar height don't
      change the frame size.  This is done so that users can create
      tall Emacs frames without having to guess how tall the tool-bar
      will get.  */
   if (toolbar_p && FRAME_TOOL_BAR_LINES (f))
     {
       int margin, relief, bar_height;

       relief = (tool_bar_button_relief >= 0
		? tool_bar_button_relief
		: DEFAULT_TOOL_BAR_BUTTON_RELIEF);

       if (INTEGERP (Vtool_bar_button_margin)
	  && XINT (Vtool_bar_button_margin) > 0)
	margin = XFASTINT (Vtool_bar_button_margin);
       else if (CONSP (Vtool_bar_button_margin)
	       && INTEGERP (XCDR (Vtool_bar_button_margin))
	       && XINT (XCDR (Vtool_bar_button_margin)) > 0)
	margin = XFASTINT (XCDR (Vtool_bar_button_margin));
       else
	margin = 0;

       bar_height = DEFAULT_TOOL_BAR_IMAGE_HEIGHT + 2 * margin + 2 * relief;
       FRAME_LINES (f) += (bar_height + FRAME_LINE_HEIGHT (f) - 1) / FRAME_LINE_HEIGHT (f);
     }

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Richard Stallman]

Perhaps I have misunderstood the nature of the problem.  I thought the
problem was that the height in default-frame-alist was being ignored
entirely for the first frame, from these words:

     >     Yes they do.  It looks like default-frame-alist is ignored for the first frame.

My experience is that it is not ignored.

You're now talking about a completely different problem:

    Commenting out the following stretch from frame.c fixes the bug for me.

       /* This used to be done _before_ calling x_figure_window_size, but
	  since the height is reset here, this was really a no-op.  I
	  assume that moving it here does what Gerd intended (although he
	  no longer can remember what that was...  ++KFS, 2003-03-25.  */
       ....

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.

    The size of the initial frame seems correct because initial frames get
    the same height regardless of whether they have a tool-bar or not (if
    they didn't we'd probably have another bug).

Could you explain that precisely?  Perhaps that special feature for -g
and the initial frame needs to be implemented in a different place.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[martin rudalics]

 > Perhaps I have misunderstood the nature of the problem.  I thought the
 > problem was that the height in default-frame-alist was being ignored
 > entirely for the first frame, from these words:
 >
 >      >     Yes they do.  It looks like default-frame-alist is ignored for the first frame.
 >
 > My experience is that it is not ignored.
 >
 > You're now talking about a completely different problem:

Your experience and mine are identic but the problem goes as follows:
The OP observed that the height of the initial (first) frame differs
from that of additional frames.  We found out that their heights differ
by the height of the toolbar, that is, additional frames are by the
height of the toolbar higher than the initial (first) frame.  So if you
say that the initial frame is good, the bug must be with the additional
frames and _not_ with the initial one.  Hence we've been discussing the
problem with different premises.

 >     Commenting out the following stretch from frame.c fixes the bug for me.
 >
 >        /* This used to be done _before_ calling x_figure_window_size, but
 > 	  since the height is reset here, this was really a no-op.  I
 > 	  assume that moving it here does what Gerd intended (although he
 > 	  no longer can remember what that was...  ++KFS, 2003-03-25.  */
 >        ....
 >
 > 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.

As Jan said this code is executed exclusively with the native toolbar,
hence we would have to judge whether not executing that code DTRT for
toolkit scrollbars.  With the native toolbar, this code is not executed
for the initial frame (at least not here), hence we would have to judge
whether not executing that code for the initial frame does TRT.  Here,
this code gets executed only for additional frames and iff I have
toolbars enabled.

 >     The size of the initial frame seems correct because initial frames get
 >     the same height regardless of whether they have a tool-bar or not (if
 >     they didn't we'd probably have another bug).
 >
 > Could you explain that precisely?  Perhaps that special feature for -g
 > and the initial frame needs to be implemented in a different place.

Please recall that I didn't use -g to produce the bug, just a
single-line .emacs containing

(add-to-list 'default-frame-alist '(height . 37))

What I wanted to express above is that my initial Emacs frame has the
same height regardless of whether I have toolbars enabled or not.  Also,
the heights of my frames never change when I switch toolbars on and off.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Robert J. Chassell]

    Today's GNU Emacs CVS snapshot, Fri, 2007 Dec 28  11:02 UTC
    GNU Emacs 23.0.50.12 (i686-pc-linux-gnu, GTK+ Version 2.12.1)
    started with:

      /usr/local/src/emacs/src/emacs -Q -D \
       --eval '(setq-default mode-line-buffer-identification
                             (quote (#("%14b" 0 4 (face (:weight normal))))))' \
       -fn "-Misc-Fixed-Medium-R-Normal--20-200-75-75-C-100-ISO8859-1" \
       --visit=/usr/local/bin/emacs-test                               \
       --eval "(setq frame-title-format '(\"Emacs test:  %b\"))"       \
       --eval '(set-frame-name "Emacs test")'                          \
       --eval '(switch-to-buffer "*scratch*")'                         \
       --eval '(emacs-version t)'


martin rudalics said,

    What I wanted to express above is that my initial Emacs frame has
    the same height regardless of whether I have toolbars enabled or
    not.

That is a different issue than RMS was dealing  with.  As far as I
understand, he was concerned with the number of lines of text.

Toolbars on my system take up two lines and the heights of an Emacs
instance in X, the first frame, changes, although at the moment the
number of text lines stay the same regardless whether I evaluate

    (tool-bar-mode 0)
or
    (tool-bar-mode 1)

(As I said earlier, the height of the first frame changes.)

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

--
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[martin rudalics]

 >     What I wanted to express above is that my initial Emacs frame has
 >     the same height regardless of whether I have toolbars enabled or
 >     not.
 >
 > That is a different issue than RMS was dealing  with.  As far as I
 > understand, he was concerned with the number of lines of text.

Apparently for Gtk+ users the height changes but the number of visible
lines remains the same when toggling `tool-bar-mode'.  For native
toolbar users the height remains the same and the number of visible
lines changes.  I reported this only to explain the behavior of Emacs
with native toolbars as seen here.

 > Toolbars on my system take up two lines and the heights of an Emacs
 > instance in X, the first frame, changes, although at the moment the
 > number of text lines stay the same regardless whether I evaluate
 >
 >     (tool-bar-mode 0)
 > or
 >     (tool-bar-mode 1)
 >
 > (As I said earlier, the height of the first frame changes.)
 >
 > I like it that the number of lines of text stays the same.

If I had two Emacs frames aligned one above the other I probably would
mind if one of them changed size without being asked to do so.  But I
can't really tell because I don't use toolbars and never count the
number of lines of frames - my Emcas always runs full screen.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Jan Djärv]

martin rudalics skrev:
>>     What I wanted to express above is that my initial Emacs frame has
>>     the same height regardless of whether I have toolbars enabled or
>>     not.
>>
>> That is a different issue than RMS was dealing  with.  As far as I
>> understand, he was concerned with the number of lines of text.
> 
> Apparently for Gtk+ users the height changes but the number of visible
> lines remains the same when toggling `tool-bar-mode'.  For native
> toolbar users the height remains the same and the number of visible
> lines changes.  I reported this only to explain the behavior of Emacs
> with native toolbars as seen here.

Yes this is one of many symptoms of bugs in the Emacs-Gtk+ resize code.  Is is
mainly due to my misunderstanding of both Gtk+ resize handling and Emacs
resize handling.  This time two wrongs did not make one right :-).

I'm working on it, but there are still some time before I can check something in.

	Jan D.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[martin rudalics]

 >>Apparently for Gtk+ users the height changes but the number of visible
 >>lines remains the same when toggling `tool-bar-mode'.  For native
 >>toolbar users the height remains the same and the number of visible
 >>lines changes.  I reported this only to explain the behavior of Emacs
 >>with native toolbars as seen here.
 >
 >
 > Yes this is one of many symptoms of bugs in the Emacs-Gtk+ resize code.  Is is
 > mainly due to my misunderstanding of both Gtk+ resize handling and Emacs
 > resize handling.  This time two wrongs did not make one right :-).

Did we already settle on a "right" way to do this?  Robert expressed the
desire to keep the number of text lines invariant.  ISTR others wanted
the size of the frame on the screen stay invariant.  At least a similar
issue was recently brought up for menubars.  Finally, I'm interested how
changes of menu-bar-lines/tool-bar-lines are supposed to be applied and
handled - I'm quite lost in this context.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Jan Djärv]

martin rudalics skrev:
>>>Apparently for Gtk+ users the height changes but the number of visible
>>>lines remains the same when toggling `tool-bar-mode'.  For native
>>>toolbar users the height remains the same and the number of visible
>>>lines changes.  I reported this only to explain the behavior of Emacs
>>>with native toolbars as seen here.
>>
>>
>> Yes this is one of many symptoms of bugs in the Emacs-Gtk+ resize
> code.  Is is
>> mainly due to my misunderstanding of both Gtk+ resize handling and Emacs
>> resize handling.  This time two wrongs did not make one right :-).
> 
> Did we already settle on a "right" way to do this?  Robert expressed the
> desire to keep the number of text lines invariant.  ISTR others wanted
> the size of the frame on the screen stay invariant.  At least a similar
> issue was recently brought up for menubars.  Finally, I'm interested how
> changes of menu-bar-lines/tool-bar-lines are supposed to be applied and
> handled - I'm quite lost in this context.
> 
> 

I don't think we did.  But frame size can't in general stay constant as we
have wm hints.  For example, I have 13 pixels of text height.  That gives min
resize 13.  The tool bar is 36 pixels.  So when the tool bar goes, either we
increase text size by 3 (== 39, 3 additional pixels) or by 2 (26, decrease by
10 pixels).

I'll implement whatever seems easiest, and then people can suggest
alternatives after that.

	Jan D.

RE: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Drew Adams]

> > Did we already settle on a "right" way to do this?  Robert expressed the
> > desire to keep the number of text lines invariant.  ISTR others wanted
> > the size of the frame on the screen stay invariant.  At least a similar
> > issue was recently brought up for menubars.  Finally, I'm interested how
> > changes of menu-bar-lines/tool-bar-lines are supposed to be applied and
> > handled - I'm quite lost in this context.
>
> I don't think we did.  But frame size can't in general stay constant as
> we have wm hints.  For example, I have 13 pixels of text height.
> That gives min resize 13.  The tool bar is 36 pixels.  So when the
> tool bar goes, either we increase text size by 3 (== 39, 3
> additional pixels) or by 2 (26, decrease by 10 pixels).
>
> I'll implement whatever seems easiest, and then people can suggest
> alternatives after that.

The fact that it is not always possible to maintain exactly the same overall
frame size because that size is not always an integral number of characters
is not a reason to not try to maintain the size as closely as possible.
Please don't simply "implement whatever seems easiest".

It is likely that there are different preferences for this based on
different uses of frames.

Someone who typically uses frames (e.g. non-nil pop-up-frames) might want
the frame size to remain the same (or as close to that as possible). Such a
user will want to fit frames, tile them, and perform other operations for
which the overall (outside) frame dimensions are significant. I and some
others are in this group.

Someone else might want the text content within the frame to remain
constant. Such a user might not care so much about the outside frame
dimensions.

The right approach to this is to provide a user option for it. There is no
sense arguing over which frame-size treatment is best in this regard, and it
does not make sense to simply code "whatever seems easiest" and then
entertain suggestions for changes after that.

Let's try to get it right now, and provide an option to let users choose the
behavior they want - different users use frames differently. We know that
character size does not always map exactly to pixel size, but that's not a
reason to not try to DTRT.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Robert J. Chassell]

    Someone else might want the text content within the frame to
    remain constant.  Such a user might not care so much about the
    outside frame dimensions.

    The right approach to this is to provide a user option for it. ...

Drew is right.  I want `the text content within the frame to remain
constant.'  Others may want the frame size to remain constant and not
care about the text.  

I will set the user option in my .emacs file after I learn about it
unless the default is to keep the text content constant.  (However, I
note that Emacs advertises itself as a text editor rather than as a
Window manager; so maybe it will keep a good default, although its
self-description is wrong.  A program that is more than a text editor,
such as a Window manager that has footnotes in Texinfo, may not keep
`the text content constant' by default.  I should add, that from
Texinfo mode in Emacs, you can directly create seven output formats
from a single source file.  That is better than any other formatter or
`word processor' I have seen with the exception of DebianDoc, which
converts to Texinfo.)

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Jan Djärv]

Drew Adams skrev:
>>> Did we already settle on a "right" way to do this?  Robert expressed the
>>> desire to keep the number of text lines invariant.  ISTR others wanted
>>> the size of the frame on the screen stay invariant.  At least a similar
>>> issue was recently brought up for menubars.  Finally, I'm interested how
>>> changes of menu-bar-lines/tool-bar-lines are supposed to be applied and
>>> handled - I'm quite lost in this context.
>> I don't think we did.  But frame size can't in general stay constant as
>> we have wm hints.  For example, I have 13 pixels of text height.
>> That gives min resize 13.  The tool bar is 36 pixels.  So when the
>> tool bar goes, either we increase text size by 3 (== 39, 3
>> additional pixels) or by 2 (26, decrease by 10 pixels).
>>
>> I'll implement whatever seems easiest, and then people can suggest
>> alternatives after that.
> 
> The fact that it is not always possible to maintain exactly the same overall
> frame size because that size is not always an integral number of characters
> is not a reason to not try to maintain the size as closely as possible.
> Please don't simply "implement whatever seems easiest".

This is a Gtk+ issue that taken up a lot of my time lately.  Unless you are 
willing to contribute code, the easiest thing is what I will do.  This is code 
that is hard to get right, so making a complex solution is out of the question.

	Jan D.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Richard Stallman]

    Did we already settle on a "right" way to do this?  Robert expressed the
    desire to keep the number of text lines invariant.  ISTR others wanted
    the size of the frame on the screen stay invariant.

Ideally, the tool bar ought to work like the menu bar:
turning it on or off should not affect the height of the text area.

Re: [Fwd: Frame Height Different for Default Frame and Additional Frames]

[Stefan Monnier]

>     Did we already settle on a "right" way to do this?  Robert expressed the
>     desire to keep the number of text lines invariant.  ISTR others wanted
>     the size of the frame on the screen stay invariant.

> Ideally, the tool bar ought to work like the menu bar:
> turning it on or off should not affect the height of the text area.

Well, in my world, the The Right Thing is to not change the size of the
frame unless explicitly requested, so adding a toolbar or menubar should
reduce the amount of text displayed.

But clearly in other worlds, the convention is different (e.g. macosx
users probably expect the toolbar to change the size of the whole frame).


        Stefan

RE: [Fwd: Frame Height Different for Default Frame and AdditionalFrames]

[Drew Adams]

> >     Did we already settle on a "right" way to do this?  Robert 
> >     expressed the desire to keep the number of text lines invariant.
> >     ISTR others wanted the size of the frame on the screen stay
> >     invariant.
> 
> > Ideally, the tool bar ought to work like the menu bar:
> > turning it on or off should not affect the height of the text area.
> 
> Well, in my world, the The Right Thing is to not change the size of the
> frame unless explicitly requested, so adding a toolbar or menubar should
> reduce the amount of text displayed.
> 
> But clearly in other worlds, the convention is different (e.g. macosx
> users probably expect the toolbar to change the size of the whole frame).

That's what I said too:

   It is likely that there are different preferences for this
   based on different uses of frames.

We should have a user option for this:

   The right approach to this is to provide a user option for it.
   There is no sense arguing over which frame-size treatment is best
   in this regard