Frame size changes

Frame size changes

[Chong Yidong]

For a while, there's been a bug regarding erratic frame sizing: see
bug#598, possibly also bug#708.

I've been able to reproduce this using the Terminus font (for those
using Debian or Ubuntu, this is from the xfonts-terminus package).  When
this font is used, the initial frame size is unpredictable.

This seems to arise from ConfigureNotify events that Emacs receives,
which causes its frame size in rows/columns to change (because of the
ConfigureNotify event, handle_one_xevent (xterm.c:6774) calls
xg_frame_resized (gtkutil.c:642), which changes the frame size.

I don't know why these ConfigureNotify events are issued.  It's strange,
because none of the changes during the startup process ought to change
the number or rows/columns in the initial frame.  Another strange thing
is that this happens with the Terminus font, but not other fonts I've
tried.

Does anyone have ideas about what's causing this?

Re: Frame size changes

[Jan Djärv]

Chong Yidong skrev:
> For a while, there's been a bug regarding erratic frame sizing: see
> bug#598, possibly also bug#708.
> 
> I've been able to reproduce this using the Terminus font (for those
> using Debian or Ubuntu, this is from the xfonts-terminus package).  When
> this font is used, the initial frame size is unpredictable.
> 
> This seems to arise from ConfigureNotify events that Emacs receives,
> which causes its frame size in rows/columns to change (because of the
> ConfigureNotify event, handle_one_xevent (xterm.c:6774) calls
> xg_frame_resized (gtkutil.c:642), which changes the frame size.
> 
> I don't know why these ConfigureNotify events are issued.  It's strange,
> because none of the changes during the startup process ought to change
> the number or rows/columns in the initial frame.  Another strange thing
> is that this happens with the Terminus font, but not other fonts I've
> tried.
> 
> Does anyone have ideas about what's causing this?


If this only happens for the first frame but not for frames created later, I
think it is the interraction between Emacs and the window manager and the fact
that Emacs adjust frame size a lot during startup.

Something like this:
Emacs calculates the frame size based on some initial font, and sets wm
manager hints based on that (i.e. restricts width/height to a multiple of the
font width/height).

Then Emacs reads .emacs and that changes the font, thus a new size and a new
wm hints is calculated and a new frame size is set.

To complicate things further, either the tool bar and/or the menu bar may be
added/removed, thus the frame size is changed again.

The window manager applies the size hints and sends configure notify to Emacs
when it does.  But if Emacs has read the second font size before the
ConfigureNotify for the first font size changes arrives, things get strange.
The window manager bases the size on the first font, but Emacs bases it on the
second.  So when Emacs tries to cope, it probably does a resize again (because
the fonts sizes differ and we want the frame to be a multiple of the font
size).  This may lead to another ConfigureNotify, which may be based on the
first or second font size (resize from Emacs and setting of wm hints does not
go the same way and can be seen out of order by the WM), there is a race
there.  And the same thing happens again.

This should not happen on frames created after the first one, because at that
point we know the font to use, so no font changes (and wm hint changes) needs
to take place.

This is tricky.  Iäve tried many solutions but they all fail in some case or
another, or with some WM (this is WM dependent also).  I think the only proper
solution to this is to make Emacs read .emacs before it maps the first frame.

	Jan D.

Re: Frame size changes

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Emacs calculates the frame size based on some initial font, and sets
> wm manager hints based on that (i.e. restricts width/height to a
> multiple of the font width/height).
>
> Then Emacs reads .emacs and that changes the font, thus a new size and
> a new wm hints is calculated and a new frame size is set.
>
> The window manager applies the size hints and sends configure notify
> to Emacs when it does.  But if Emacs has read the second font size
> before the ConfigureNotify for the first font size changes arrives,
> things get strange.  The window manager bases the size on the first
> font, but Emacs bases it on the second.  So when Emacs tries to cope,
> it probably does a resize again (because the fonts sizes differ and we
> want the frame to be a multiple of the font size).  This may lead to
> another ConfigureNotify, which may be based on the first or second
> font size (resize from Emacs and setting of wm hints does not go the
> same way and can be seen out of order by the WM), there is a race
> there.  And the same thing happens again.

Thanks for the explanation.  I think this is indeed the problem.

The straightforward fix is for Emacs to wait until the window manager
gets back with the ConfigureNotify before proceeding.  From looking at
gtkutil.c, it seems like you use the function flush_and_sync for a
similar reason.  The problem, I'm guessing, is that we aren't guaranteed
that the window manager will have a response ready during the
flush_and_sync.

If so, how about changing flush_and_sync to be more aggressive, and
demanding a ConfigureNotify before proceeding?

> I've tried many solutions but they all fail in some case or another..
> I think the only proper solution to this is to make Emacs read .emacs
> before it maps the first frame.

This would be a big incompatible change, and at this point in the
release cycle we must exhaust all other workarounds before considering
it.

Re: Frame size changes

[Jan Djärv]

Chong Yidong skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Emacs calculates the frame size based on some initial font, and sets
>> wm manager hints based on that (i.e. restricts width/height to a
>> multiple of the font width/height).
>>
>> Then Emacs reads .emacs and that changes the font, thus a new size and
>> a new wm hints is calculated and a new frame size is set.
>>
>> The window manager applies the size hints and sends configure notify
>> to Emacs when it does.  But if Emacs has read the second font size
>> before the ConfigureNotify for the first font size changes arrives,
>> things get strange.  The window manager bases the size on the first
>> font, but Emacs bases it on the second.  So when Emacs tries to cope,
>> it probably does a resize again (because the fonts sizes differ and we
>> want the frame to be a multiple of the font size).  This may lead to
>> another ConfigureNotify, which may be based on the first or second
>> font size (resize from Emacs and setting of wm hints does not go the
>> same way and can be seen out of order by the WM), there is a race
>> there.  And the same thing happens again.
> 
> Thanks for the explanation.  I think this is indeed the problem.
> 
> The straightforward fix is for Emacs to wait until the window manager
> gets back with the ConfigureNotify before proceeding.  From looking at
> gtkutil.c, it seems like you use the function flush_and_sync for a
> similar reason.  The problem, I'm guessing, is that we aren't guaranteed
> that the window manager will have a response ready during the
> flush_and_sync.

Yes, it is an attempt to make things better.  I also tried turning off wm 
hints while resizing, but that only lead to more problems (i.e. we are not 
guaranteed that the wm gets the off message before the resize, and so on...).


> 
> If so, how about changing flush_and_sync to be more aggressive, and
> demanding a ConfigureNotify before proceeding?

In some cases there will be no ConfigureNotify.  If we go down this path, we 
must have a reasonable timeout.  I don't know exactly, but around one second? 
  The thing is when I use Emacs over a slow line, a second is too fast, but 
for normal local uses it will be OK.


> 
>> I've tried many solutions but they all fail in some case or another..
>> I think the only proper solution to this is to make Emacs read .emacs
>> before it maps the first frame.
> 
> This would be a big incompatible change, and at this point in the
> release cycle we must exhaust all other workarounds before considering
> it.

Yes I know.  I only mentioned it because I seem to recall some of those Emacs 
variants out there doing this already (Aquaemacs perhaps?).

	Jan D.

Re: Frame size changes

[Stefan Monnier]

>>> I've tried many solutions but they all fail in some case or another..
>>> I think the only proper solution to this is to make Emacs read .emacs
>>> before it maps the first frame.
>> This would be a big incompatible change, and at this point in the
>> release cycle we must exhaust all other workarounds before considering
>> it.
> Yes I know.  I only mentioned it because I seem to recall some of those
> Emacs variants out there doing this already (Aquaemacs perhaps?).

Don't know about "out there" but the Emacs I use most of the time has
exactly such a change.  E.g. All the messages from the .emacs appear
on stdout.  But it's not quite right yet: "emacs -f gnus" still sees some
resizing.


        Stefan

Re: Frame size changes

[Chong Yidong]

How about the proposed solution (patch included):

The variable after-init-time (new to Emacs 23) is set to `current-time'
after initialization.  Since it's nil during initialization, we can use
it to tell if Emacs is currently being initialized.  Suppose we make
after-init-time a built-in variable.  Then, make x_wm_set_size_hint a
no-op when after-init-time is nil.  The result is that WM hints are not
set during initialization.

According to my (non-thorough) testing, this eliminates the erratic
frame sizing during startup, without introducing any other ill effects.

What do you think?


*** trunk/lisp/startup.el.~1.507.~	2008-10-02 16:21:54.000000000 -0400
--- trunk/lisp/startup.el	2008-10-05 14:17:47.000000000 -0400
***************
*** 257,268 ****
  therefore, if you set `debug-on-error' non-nil in `.emacs',
  an error in one of these functions will invoke the debugger.")
  
- (defvar before-init-time nil
-   "Value of `current-time' before Emacs begins initialization.")
- 
- (defvar after-init-time nil
-   "Value of `current-time' after loading the init files.")
- 
  (defvar emacs-startup-hook nil
    "Normal hook run after loading init files and handling the command line.")
  
--- 257,262 ----

*** trunk/src/lisp.h.~1.644.~	2008-09-24 16:14:33.000000000 -0400
--- trunk/src/lisp.h	2008-10-05 14:23:45.000000000 -0400
***************
*** 3102,3107 ****
--- 3102,3108 ----
  /* defined in emacs.c */
  extern Lisp_Object decode_env_path P_ ((char *, char *));
  extern Lisp_Object Vinvocation_name, Vinvocation_directory;
+ extern Lisp_Object Vbefore_init_time, Vafter_init_time;
  extern Lisp_Object Vinstallation_directory;
  extern Lisp_Object empty_unibyte_string, empty_multibyte_string;
  EXFUN (Fkill_emacs, 1);
*** trunk/src/emacs.c.~1.447.~	2008-10-05 14:07:06.000000000 -0400
--- trunk/src/emacs.c	2008-10-05 14:27:01.000000000 -0400
***************
*** 131,136 ****
--- 131,139 ----
     nil means get them only from PATH_LOADSEARCH.  */
  Lisp_Object Vinstallation_directory;
  
+ /* The values of `current-time' before and after Emacs initialization.  */
+ Lisp_Object Vbefore_init_time, Vafter_init_time;
+ 
  /* Hook run by `kill-emacs' before it does really anything.  */
  Lisp_Object Vkill_emacs_hook;
  
***************
*** 2497,2502 ****
--- 2500,2513 ----
    DEFVAR_LISP ("previous-system-time-locale", &Vprevious_system_time_locale,
  	       doc: /* Most recently used system locale for time.  */);
    Vprevious_system_time_locale = Qnil;
+ 
+   DEFVAR_LISP ("before-init-time", &Vbefore_init_time,
+ 	       doc: /* Value of `current-time' before Emacs begins initialization.  */);
+   Vbefore_init_time = Qnil;
+ 
+   DEFVAR_LISP ("after-init-time", &Vafter_init_time,
+ 	       doc: /* Value of `current-time' after loading the init files.  */);
+   Vafter_init_time = Qnil;
  }
  
  /* arch-tag: 7bfd356a-c720-4612-8ab6-aa4222931c2e
*** trunk/src/gtkutil.c.~1.138.~	2008-07-29 12:15:41.000000000 -0400
--- trunk/src/gtkutil.c	2008-10-05 14:22:01.000000000 -0400
***************
*** 934,939 ****
--- 934,942 ----
       long flags;
       int user_position;
  {
+   if (NILP (Vafter_init_time))
+     return;
+ 
    if (FRAME_GTK_OUTER_WIDGET (f))
    {
      /* Must use GTK routines here, otherwise GTK resets the size hints

Re: Frame size changes

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 05 Oct 2008 14:35:09 -0400
> Cc: emacs-devel@gnu.org
> 
> The variable after-init-time (new to Emacs 23) is set to `current-time'
> after initialization.  Since it's nil during initialization, we can use
> it to tell if Emacs is currently being initialized.  Suppose we make
> after-init-time a built-in variable.  Then, make x_wm_set_size_hint a
> no-op when after-init-time is nil.  The result is that WM hints are not
> set during initialization.

If all you need is a flag saying that Emacs is being initialized, why
does it have to bear the value of current-time? why not just some
simple predicate?  What am I missing?

Re: Frame size changes

[Jan Djärv]

Chong Yidong skrev:
> How about the proposed solution (patch included):
> 
> The variable after-init-time (new to Emacs 23) is set to `current-time'
> after initialization.  Since it's nil during initialization, we can use
> it to tell if Emacs is currently being initialized.  Suppose we make
> after-init-time a built-in variable.  Then, make x_wm_set_size_hint a
> no-op when after-init-time is nil.  The result is that WM hints are not
> set during initialization.
> 
> According to my (non-thorough) testing, this eliminates the erratic
> frame sizing during startup, without introducing any other ill effects.
> 
> What do you think?

Sounds very interesting.  I'd say check it in so we can get it tested by 
pretesters.  Good work!


	Jan D.

> 
> 
> *** trunk/lisp/startup.el.~1.507.~	2008-10-02 16:21:54.000000000 -0400
> --- trunk/lisp/startup.el	2008-10-05 14:17:47.000000000 -0400
> ***************
> *** 257,268 ****
>   therefore, if you set `debug-on-error' non-nil in `.emacs',
>   an error in one of these functions will invoke the debugger.")
>   
> - (defvar before-init-time nil
> -   "Value of `current-time' before Emacs begins initialization.")
> - 
> - (defvar after-init-time nil
> -   "Value of `current-time' after loading the init files.")
> - 
>   (defvar emacs-startup-hook nil
>     "Normal hook run after loading init files and handling the command line.")
>   
> --- 257,262 ----
> 
> *** trunk/src/lisp.h.~1.644.~	2008-09-24 16:14:33.000000000 -0400
> --- trunk/src/lisp.h	2008-10-05 14:23:45.000000000 -0400
> ***************
> *** 3102,3107 ****
> --- 3102,3108 ----
>   /* defined in emacs.c */
>   extern Lisp_Object decode_env_path P_ ((char *, char *));
>   extern Lisp_Object Vinvocation_name, Vinvocation_directory;
> + extern Lisp_Object Vbefore_init_time, Vafter_init_time;
>   extern Lisp_Object Vinstallation_directory;
>   extern Lisp_Object empty_unibyte_string, empty_multibyte_string;
>   EXFUN (Fkill_emacs, 1);
> *** trunk/src/emacs.c.~1.447.~	2008-10-05 14:07:06.000000000 -0400
> --- trunk/src/emacs.c	2008-10-05 14:27:01.000000000 -0400
> ***************
> *** 131,136 ****
> --- 131,139 ----
>      nil means get them only from PATH_LOADSEARCH.  */
>   Lisp_Object Vinstallation_directory;
>   
> + /* The values of `current-time' before and after Emacs initialization.  */
> + Lisp_Object Vbefore_init_time, Vafter_init_time;
> + 
>   /* Hook run by `kill-emacs' before it does really anything.  */
>   Lisp_Object Vkill_emacs_hook;
>   
> ***************
> *** 2497,2502 ****
> --- 2500,2513 ----
>     DEFVAR_LISP ("previous-system-time-locale", &Vprevious_system_time_locale,
>   	       doc: /* Most recently used system locale for time.  */);
>     Vprevious_system_time_locale = Qnil;
> + 
> +   DEFVAR_LISP ("before-init-time", &Vbefore_init_time,
> + 	       doc: /* Value of `current-time' before Emacs begins initialization.  */);
> +   Vbefore_init_time = Qnil;
> + 
> +   DEFVAR_LISP ("after-init-time", &Vafter_init_time,
> + 	       doc: /* Value of `current-time' after loading the init files.  */);
> +   Vafter_init_time = Qnil;
>   }
>   
>   /* arch-tag: 7bfd356a-c720-4612-8ab6-aa4222931c2e
> *** trunk/src/gtkutil.c.~1.138.~	2008-07-29 12:15:41.000000000 -0400
> --- trunk/src/gtkutil.c	2008-10-05 14:22:01.000000000 -0400
> ***************
> *** 934,939 ****
> --- 934,942 ----
>        long flags;
>        int user_position;
>   {
> +   if (NILP (Vafter_init_time))
> +     return;
> + 
>     if (FRAME_GTK_OUTER_WIDGET (f))
>     {
>       /* Must use GTK routines here, otherwise GTK resets the size hints
> 

Re: Frame size changes

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> If all you need is a flag saying that Emacs is being initialized, why
> does it have to bear the value of current-time? why not just some
> simple predicate?  What am I missing?

before-init-time and after-init-time have already been introduced in
Emacs 23; see NEWS.  The former is used for the new function
emacs-uptime, the latter I'm unsure about.

Since these variables already exist, my feeling is that it's better to
use them rather than to come up with a new flag saying that Emacs is
being initialized.

Re: Frame size changes

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sun, 05 Oct 2008 17:11:38 -0400
> Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If all you need is a flag saying that Emacs is being initialized, why
> > does it have to bear the value of current-time? why not just some
> > simple predicate?  What am I missing?
> 
> before-init-time and after-init-time have already been introduced in
> Emacs 23; see NEWS.  The former is used for the new function
> emacs-uptime, the latter I'm unsure about.
> 
> Since these variables already exist, my feeling is that it's better to
> use them rather than to come up with a new flag saying that Emacs is
> being initialized.

It is still not clean, IMO, to use these variables in order to decide
if we are initializing.  For starters, I'm not sure it will work if
Emacs is dumped a second time.

Re: Frame size changes

[Lennart Borgman (gmail)]

Chong Yidong wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>> If all you need is a flag saying that Emacs is being initialized, why
>> does it have to bear the value of current-time? why not just some
>> simple predicate?  What am I missing?
> 
> before-init-time and after-init-time have already been introduced in
> Emacs 23; see NEWS.  The former is used for the new function
> emacs-uptime, the latter I'm unsure about.

The documentation for before-init-time is a bit unclear. Exactly when is
it set?

> Since these variables already exist, my feeling is that it's better to
> use them rather than to come up with a new flag saying that Emacs is
> being initialized.
> 
> 
> 

Re: Frame size changes

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> It is still not clean, IMO, to use these variables in order to decide
> if we are initializing.

I understand this concern, but on the other hand it's also not perfectly
satisfactory to introduce a separate variable either, since the
information provided by after-init-time is a strict superset of the
information given by that separate variable.

To handle the corner case where Emacs is dumped twice, we can make
startup.el reset after-init-time to nil just before it begins
initialization.  We should probably do that anyway.

Re: Frame size changes

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>> I've tried many solutions but they all fail in some case or another..
>>>> I think the only proper solution to this is to make Emacs read .emacs
>>>> before it maps the first frame.
>
> Don't know about "out there" but the Emacs I use most of the time has
> exactly such a change.  E.g. All the messages from the .emacs appear
> on stdout.

Can you post your patch?

Also, can anyone remember the reasons why such a change was originally
rejected when proposed during Emacs 21 development?

The only issues I remember were:

  (1) It might make it harder to debug problems while reading .emacs
      (maybe best handled by having --debug-init map the initial frame
      earlier)

  (2) Objections that people might use interactive forms in .emacs, but
      this seems pretty far-fetched to me

Thanks,

-Miles

-- 
Congratulation, n. The civility of envy.

Re: Frame size changes

[Juanma Barranquero]

On Mon, Oct 6, 2008 at 06:16, Miles Bader <miles.bader@necel.com> wrote:

>  (2) Objections that people might use interactive forms in .emacs, but
>      this seems pretty far-fetched to me

Why?

             Juanma

Re: Frame size changes

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>>  (2) Objections that people might use interactive forms in .emacs, but
>>      this seems pretty far-fetched to me
>
> Why?

Because it's a weird thing to do on the face of it, and I've never heard
of anybody actually doing it.

It's easy enough to _support_ that, by offering an explicit
`map-initial-frame' function that people can call if necessary.  But we
shouldn't consider it the default mode of operation.

-Miles

-- 
Opportunity, n. A favorable occasion for grasping a disappointment.

Re: Frame size changes

[Juanma Barranquero]

On Mon, Oct 6, 2008 at 15:59, Miles Bader <miles@gnu.org> wrote:

> Because it's a weird thing to do on the face of it, and I've never heard
> of anybody actually doing it.

Perhaps I'm misunderstanding "us[ing] interactive forms in .emacs".
Asking an interactive question to the user while .emacs is loaded is
not weird at all. In certain cases, I ask an interactive question from
site-lisp.el...

             Juanma

Re: Frame size changes

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> Because it's a weird thing to do on the face of it, and I've never heard
>> of anybody actually doing it.
>
> Perhaps I'm misunderstanding "us[ing] interactive forms in .emacs".
> Asking an interactive question to the user while .emacs is loaded is
> not weird at all. In certain cases, I ask an interactive question from
> site-lisp.el...

Well, we're going to have to agree to disagree then, because I think
you're wrong.

-Miles

-- 
Abstainer, n. A weak person who yields to the temptation of denying himself a
pleasure. A total abstainer is one who abstains from everything but
abstention, and especially from inactivity in the affairs of others.

Re: Frame size changes

[Juanma Barranquero]

On Mon, Oct 6, 2008 at 16:14, Miles Bader <miles@gnu.org> wrote:

> Well, we're going to have to agree to disagree then, because I think
> you're wrong.

Are we going to start dictating what it is good or wrong to do from
inside .emacs? Isn't this the Customizable, etc. etc.? That most
people do not need or use interactivity while loading .emacs does not
mean that it is wrong, or unreasonable.

             Juanma