bug#26537: Problems with Emacs frame (GTK)

bug#26537: Problems with Emacs frame (GTK)

[Angelo Graziosi]

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

In recent GTK builds of Emacs master I have issues with the frame with 
on GNU/Linux Mint 18.1 64bit.

I had installed the sr-speedbar package from MELPA and configured Emacs 
so that it opens a frame with a window for text of about 80 characters 
and a sr-speedbar window of about 30 characters (see the init.el file in 
the attachment, 80+30 = 110).

This worked fine (more or less) up to the builds I did on March 10 and 
27 but not with the builds I did on April 14 an 16 (today).

More precisely...

Start Emacs-2017-03-10 [1] without desktop file. The result is in 
screen-no-desktop.png, and don't looks ok to me. Anyway, now visit a 
file. For example

   C-x C-f ~/report_bug.txt

and quit Emacs saving the desktop. Restart Emacs. It looks as expected 
(screen-with-desktop-OK.png)

   window      width 79 characters (from column 0 to 78)
   sr-speedbar width 27 characters


Repeat with Emacs-2017-03-27 [2]. Same results.

Now try with Emacs-2017-04-14 [3] or 2017-04-16 [4]. It doesn't look as 
expected (screen-with-desktop-NOT_OK.png)

   window      width 68 characters (from column 0 to 67)
   sr-speedbar width 38 characters

(Notice: 79+27 = 68+38 = 106). Whatever I try, the frame does not 
respect what is written in the init file.

Notice this problem occurs only with the (GTK) builds on GNU/Linux. It 
works as expected with Windows and OSX builds.


Ciao,
  Angelo.

-----
[1] 996fcc74a431e6db819dae1cfbc90ffdc15a222f
[2] 8ce827426e5400f2be80ae5d7394b74d8dd90373
[3] fc05d4fec98387097c30a5c60e2f343cb797af26
[4] 8d96feae07c618f591a952f8f10ae949735b4050


[-- Attachment #2: bugrep.tar.gz --]
[-- Type: application/gzip, Size: 284594 bytes --]

bug#26537: Problems with Emacs frame (GTK)

[martin rudalics]

 > I had installed the sr-speedbar package from MELPA and configured
 > Emacs so that it opens a frame with a window for text of about 80
 > characters and a sr-speedbar window of about 30 characters (see the
 > init.el file in the attachment, 80+30 = 110).

It would be nice if you were able to excerpt the sr-speedbar
‘split-window’ call so we could distill a more simple scenario.  IIUC
this should be something like (split-window -n t) where the n should
evaluate to 30 in your case.

 > Start Emacs-2017-03-10 [1] without desktop file. The result is in
 > screen-no-desktop.png, and don't looks ok to me.

So let's look into this first.  Do you mean the speedbar window should
be wider?  In any case do M-: (window--dump-frame) and post the result
which you can find in the buffer *window-frame-dump*.

 > Anyway, now visit a file. For example
 >
 >    C-x C-f ~/report_bug.txt
 >
 > and quit Emacs saving the desktop. Restart Emacs. It looks as expected (screen-with-desktop-OK.png)
 >
 >    window      width 79 characters (from column 0 to 78)
 >    sr-speedbar width 27 characters
 >
 >
 > Repeat with Emacs-2017-03-27 [2]. Same results.
 >
 > Now try with Emacs-2017-04-14 [3] or 2017-04-16 [4]. It doesn't look as expected (screen-with-desktop-NOT_OK.png)
 >
 >    window      width 68 characters (from column 0 to 67)
 >    sr-speedbar width 38 characters
 >
 > (Notice: 79+27 = 68+38 = 106). Whatever I try, the frame does not respect what is written in the init file.

Instead of "init file" I suppose you mean "desktop" here, i.e., the file
written by desktop.el.  Right?  Or do you mean something like "what the
init file says should override what the desktop file says" (I'm not very
familiar with desktop)?  In either case the desktop file is the one you
attached.  Right?

In any case please post here the results of ‘window--dump-frame’ for

(1) the screen-with-desktop-OK frame

(2) the frame _before_ desktop saved it in the
     screen-with-desktop-NOT_OK scenario, and

(3) the frame _after_ desktop restored it in the
     screen-with-desktop-NOT_OK  scenario.

Note that each invocation of `window--dump-frame' will overwrite
*window-frame-dump*.  Please add the identifiers from your nomenclature
(screen-no-desktop, screen-with-desktop-OK, screen-with-desktop-NOT_OK)
in each case, with something like screen-with-desktop-before-saving or
so for (2).

 > Notice this problem occurs only with the (GTK) builds on GNU/Linux. It
 > works as expected with Windows and OSX builds.

Just a simple step: Does setting the variable `x-gtk-use-window-move' to
nil change anything in your scenario?  I doubt it will but who knows.

martin

bug#26537: Problems with Emacs frame (GTK)

[Angelo Graziosi]

Il 17/04/2017 10:17, martin rudalics ha scritto:
>> Start Emacs-2017-03-10 [1] without desktop file. The result is in
>> screen-no-desktop.png, and don't looks ok to me.
>
> So let's look into this first.  Do you mean the speedbar window should
> be wider?

As you can see, in the init.el file I had attached I have

(setq default-frame-alist
       '(
         (width . 110) ; character
         (height . 49) ; lines
         (font . "Monospace-11") ; font
         ))

and

(setq sr-speedbar-default-width 30)
(setq sr-speedbar-width 30)
(setq sr-speedbar-max-width 30)

which should give a frame 110 characters wide and a sr-speedbar 30 chs. 
wide.. Why then, at first start, without desktop file, I have the frame 
in screen-no-desktop.png?

>
> Instead of "init file" I suppose you mean "desktop" here, i.e., the file
> written by desktop.el.  Right?  Or do you mean something like "what the

No, init.el. The settings for sr-speedbar I cited before should set (and 
up to the builds <= 20170327, they SET) to a frame with a sr-speedbar 
window of about 30 chs. Instead now it is of about 40 chs.

Notice I do not resize the frame or windows inside it, so I would expect 
more or less the width specified in init.el..


Angelo

bug#26537: Problems with Emacs frame (GTK)

[martin rudalics]

 > As you can see, in the init.el file I had attached I have
 >
 > (setq default-frame-alist
 >        '(
 >          (width . 110) ; character
 >          (height . 49) ; lines
 >          (font . "Monospace-11") ; font
 >          ))
 >
 > and
 >
 > (setq sr-speedbar-default-width 30)
 > (setq sr-speedbar-width 30)
 > (setq sr-speedbar-max-width 30)
 >
 > which should give a frame 110 characters wide and a sr-speedbar 30
 > chs. wide.. Why then, at first start, without desktop file, I have the
 > frame in screen-no-desktop.png?

But you said that screen-no-desktop.png is from an "Emacs-2017-03-10 [1]
without desktop file" and you also said that this "worked fine (more or
less) up to the builds I did on March 10 and 27".  So I can't yet figure
out what you mean here.  Also, you didn't tell me the results of
‘window--dump-frame’ for that frame so how can I find out how widths
like 110 and 30 were interpreted?  Please clarify.

 >> Instead of "init file" I suppose you mean "desktop" here, i.e., the file
 >> written by desktop.el.  Right?  Or do you mean something like "what the
 >
 > No, init.el. The settings for sr-speedbar I cited before should set
 > (and up to the builds <= 20170327, they SET) to a frame with a
 > sr-speedbar window of about 30 chs. Instead now it is of about 40 chs.

You didn't tell me the other results of ‘window--dump-frame’ I asked for
either.  But FWIW the pngs of screen-with-desktop-NOT_OK and
screen-with-desktop-OK you attached seem at least to exhibit the same
frame width, so a change appears there only with the width of
sr-speedbar-window.  Now if I look at the desktop file you attached,
then I see there a (total-width . 41) entry for the "*SPEEDBAR*" window
and I think a "width" of 40 chs is much more appropriate than one of 30
chs.  Again it's impossible to tell anything without more exact figures
like those returned by ‘window--dump-frame’.

 > Notice I do not resize the frame or windows inside it, so I would
 > expect more or less the width specified in init.el.

I don't know enough about desktop but IIUC its ideology is to restore
the configuration from the saved desktop and to _not_ care about
`default-frame-alist'.  If there is another opinion about this I would
like to hear or read about it somwhere.

Thanks, martin

bug#26537: Problems with Emacs frame (GTK)

[Angelo Graziosi]

Il 17/04/2017 10:17, martin rudalics ha scritto:
>
> Just a simple step: Does setting the variable `x-gtk-use-window-move' to
> nil change anything in your scenario?  I doubt it will but who knows.

Yes, it changes the scenario. That setting seems to fix, at least 
partially, the issue. "partially" because sometimes Emacs starts with 
the wrong widths for text and speedbar window, but just restarting it works.

I didn't send what you have requested in previous mail because I wanted 
to try this simple step, first..

Regarding "screen-no-desktop.png" I get it with the init.el file I had 
attached with *all* builds, only that for those <= 20170327 saving the 
desktop fixed the issue regarding the speedbar width 
("screen-with-desktop-OK.png")

If you still want the results you have requested, I will try..

Angelo

bug#26537: Problems with Emacs frame (GTK)

[martin rudalics]

 >> Just a simple step: Does setting the variable `x-gtk-use-window-move' to
 >> nil change anything in your scenario?  I doubt it will but who knows.
 >
 > Yes, it changes the scenario. That setting seems to fix, at least
 > partially, the issue. "partially" because sometimes Emacs starts with
 > the wrong widths for text and speedbar window, but just restarting it
 > works.

That's bad because you sooner or later might run into troubles with
GTK+.

 > Regarding "screen-no-desktop.png" I get it with the init.el file I had
 > attached with *all* builds, only that for those <= 20170327 saving the
 > desktop fixed the issue regarding the speedbar width
 > ("screen-with-desktop-OK.png")

But relying on desktop saving to fix an issue is not the recommended
way.

 > If you still want the results you have requested, I will try..

Why "try"?  There's no black magic involved.

(1) Start Emacs with your init file only.  After that type

     M-: (window--dump-frame)

     This will create a buffer called *window-frame-dump*.  Put the
     contents of that buffer into your mail body marking them with
     "screen-no-desktop".  Exit Emacs saving the desktop.

(2) Start some pre March 27 build with the saved desktop and proceed as
     above but mark the contents with "screen-with-desktop-OK".

(3) Start current master with `x-gtk-use-window-move' t and the saved
     desktop and proceed as above but mark the contents with
     "screen-with-desktop-NOT_OK".

Then we should have enough information to tell what really goes on.

Obviously, if, without desktop restoring, the current master produces an
initial frame different from those of the earlier builds, I would want
to see the results for that one too.  But you said that they are equal.

Thanks, martin

bug#26537: Problems with Emacs frame (GTK)

[Angelo Graziosi]

I have use my init.el (in the tarball attached to the first post), i.e. 
without the setting you suggested for "x-gtk-use-window-move".

Il 17/04/2017 10:17, martin rudalics ha scritto:
>
> In any case please post here the results of ‘window--dump-frame’ for
>
> (1) the screen-with-desktop-OK frame
>

For screen-with-desktop-OK.png (from 20170327 build):

frame pixel: 1020 x 882   cols/lines: 114 x 49   units: 9 x 18
frame text pixel: 990 x 882   cols/lines: 110 x 49
tool: 0  scroll: 14/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 7>   parent: nil
pixel left: 0   top: 0   size: 1020 x 864   new: 1020
char left: 0   top: 0   size: 113 x 48   new: 113
normal: 1.0 x 1.0   new: 1.0

#<window 3 on report_bug.txt>   parent: #<window 7>
pixel left: 0   top: 0   size: 747 x 864   new: 747
char left: 0   top: 0   size: 83 x 48   new: 83
normal: 0.7323529411764707 x 1.0   new: 0.7323529411764707
body pixel: 717 x 846   char: 79 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 8 on *SPEEDBAR*>   parent: #<window 7>
pixel left: 747   top: 0   size: 273 x 864   new: 273
char left: 83   top: 0   size: 30 x 48   new: 30
normal: 0.2676470588235294 x 1.0   new: 0.2676470588235294
body pixel: 243 x 846   char: 27 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 864   size: 1020 x 18   new: 0
char left: 0   top: 48   size: 113 x 1   new: 113
normal: 1.0 x 1.0   new: 0
body pixel: 990 x 18   char: 110 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 0  divider: 0


> (2) the frame _before_ desktop saved it in the
>     screen-with-desktop-NOT_OK scenario, and

For screen-with-desktop-NOT_OK.png before saving desktop (from 20170416 
build):

frame pixel: 1020 x 882   cols/lines: 114 x 49   units: 9 x 18
frame text pixel: 990 x 882   cols/lines: 110 x 49
tool: 0  scroll: 14/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 5>   parent: nil
pixel left: 0   top: 0   size: 1020 x 864   new: 864
char left: 0   top: 0   size: 113 x 48   new: 48
normal: 1.0 x 1.0   new: nil

#<window 3 on *scratch*>   parent: #<window 5>
pixel left: 0   top: 0   size: 648 x 864   new: 864
char left: 0   top: 0   size: 72 x 48   new: 48
normal: 0.636 x 1.0   new: nil
body pixel: 618 x 846   char: 68 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 6 on *SPEEDBAR*>   parent: #<window 5>
pixel left: 648   top: 0   size: 372 x 864   new: 864
char left: 72   top: 0   size: 41 x 48   new: 48
normal: 0.364 x 1.0   new: nil
body pixel: 342 x 846   char: 38 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 864   size: 1020 x 18   new: 0
char left: 0   top: 48   size: 113 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 990 x 18   char: 110 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 0  divider: 0

>
> (3) the frame _after_ desktop restored it in the
>     screen-with-desktop-NOT_OK  scenario.

For screen-with-desktop-NOT_OK.png after desktop restored (from 20170416 
build):

frame pixel: 1020 x 882   cols/lines: 114 x 49   units: 9 x 18
frame text pixel: 990 x 882   cols/lines: 110 x 49
tool: 0  scroll: 14/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 7>   parent: nil
pixel left: 0   top: 0   size: 1020 x 864   new: 864
char left: 0   top: 0   size: 113 x 48   new: 48
normal: 1.0 x 1.0   new: nil

#<window 3 on *scratch*>   parent: #<window 7>
pixel left: 0   top: 0   size: 648 x 864   new: 864
char left: 0   top: 0   size: 72 x 48   new: 48
normal: 0.636 x 1.0   new: nil
body pixel: 618 x 846   char: 68 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 8 on *SPEEDBAR*>   parent: #<window 7>
pixel left: 648   top: 0   size: 372 x 864   new: 864
char left: 72   top: 0   size: 41 x 48   new: 48
normal: 0.364 x 1.0   new: nil
body pixel: 342 x 846   char: 38 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 864   size: 1020 x 18   new: 0
char left: 0   top: 48   size: 113 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 990 x 18   char: 110 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 0  divider: 0

bug#26537: Problems with Emacs frame (GTK)

[martin rudalics]

Thanks for the dumps.  I see no problems with the frame size so I will
concentrate on the "window width" issue.  Thet fact that setting
‘x-gtk-use-window-move’ can affect the behavior is strange enough to
warrant deeper investigation.

 > For screen-with-desktop-OK.png (from 20170327 build):

 > #<window 3 on report_bug.txt>   parent: #<window 7>
 > char left: 0   top: 0   size: 83 x 48   new: 83

 > #<window 8 on *SPEEDBAR*>   parent: #<window 7>
 > char left: 83   top: 0   size: 30 x 48   new: 30

Here *SPEEDBAR* has a width of 30 characters which is what you wanted in
the first place according to your init.el.  But I have no idea how you
got there.  IIUC your steps were:

(1) Create an initial frame without any desktop involvement.  This
     should be the frame from screen-no-desktop.png.  I would need the
     dump for that frame (from a 20170327 build) first.  And, if it is
     different, a dump of that frame just before you save the desktop.  I
     suppose the screen-with-desktop-OK dump above then would stem from a
     new session using a desktop equivalent to the one saved here.  Is
     that assumption correct?

(2) Next you would have to repeat step (1) for the 20170416 build with
     `x-gtk-use-window-move' at its default t.

If the figures reported for (1) and (2) are both wrong (i.e., the
*SPEEDBAR* is initially not 30 characters wide), we would have to
investigate why.  If the figures reported for (1) and (2) differ, we'd
have to investigate that as well.

 > For screen-with-desktop-NOT_OK.png before saving desktop (from 20170416 build):

 > #<window 3 on *scratch*>   parent: #<window 5>
 > char left: 0   top: 0   size: 72 x 48   new: 48

 > #<window 6 on *SPEEDBAR*>   parent: #<window 5>
 > char left: 72   top: 0   size: 41 x 48   new: 48

Here *SPEEDBAR* has a width of 41 characters which is correctly
preserved in the dump below.

 > For screen-with-desktop-NOT_OK.png after desktop restored (from 20170416 build):

 > #<window 3 on *scratch*>   parent: #<window 7>
 > char left: 0   top: 0   size: 72 x 48   new: 48

 > #<window 8 on *SPEEDBAR*>   parent: #<window 7>
 > char left: 72   top: 0   size: 41 x 48   new: 48

If you think that this behavior is wrong, we'll have to discuss the
principles of the desktop save & restore policy.

If, as you said before, the behavior on Windows deviates from the one
observed here, it would be instructive to see the corresponding frame
dumps for the Windows build as well.

Thanks again, martin

bug#26537: Problems with Emacs frame (GTK)

[Angelo Graziosi]

Il 17/04/2017 17:43, martin rudalics ha scritto:
>
> (1) Create an initial frame without any desktop involvement.  This
>     should be the frame from screen-no-desktop.png.  I would need the
>     dump for that frame (from a 20170327 build) first.  And, if it is
>     different, a dump of that frame just before you save the desktop.  I
>     suppose the screen-with-desktop-OK dump above then would stem from a
>     new session using a desktop equivalent to the one saved here.  Is
>     that assumption correct?


 From 20170327 build WITHOUT desktop file:


frame pixel: 1020 x 882   cols/lines: 114 x 49   units: 9 x 18
frame text pixel: 990 x 882   cols/lines: 110 x 49
tool: 0  scroll: 14/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 5>   parent: nil
pixel left: 0   top: 0   size: 1020 x 864   new: 864
char left: 0   top: 0   size: 113 x 48   new: 48
normal: 1.0 x 1.0   new: nil

#<window 3 on *scratch*>   parent: #<window 5>
pixel left: 0   top: 0   size: 648 x 864   new: 864
char left: 0   top: 0   size: 72 x 48   new: 48
normal: 0.636 x 1.0   new: nil
body pixel: 618 x 846   char: 68 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 6 on *SPEEDBAR*>   parent: #<window 5>
pixel left: 648   top: 0   size: 372 x 864   new: 864
char left: 72   top: 0   size: 41 x 48   new: 48
normal: 0.364 x 1.0   new: nil
body pixel: 342 x 846   char: 38 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 864   size: 1020 x 18   new: 0
char left: 0   top: 48   size: 113 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 990 x 18   char: 110 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 0  divider: 0

>
> (2) Next you would have to repeat step (1) for the 20170416 build with
>     `x-gtk-use-window-move' at its default t.


 From 20170416 build WITHOUT desktop file


frame pixel: 1020 x 882   cols/lines: 114 x 49   units: 9 x 18
frame text pixel: 990 x 882   cols/lines: 110 x 49
tool: 0  scroll: 14/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 5>   parent: nil
pixel left: 0   top: 0   size: 1020 x 864   new: 864
char left: 0   top: 0   size: 113 x 48   new: 48
normal: 1.0 x 1.0   new: nil

#<window 3 on *scratch*>   parent: #<window 5>
pixel left: 0   top: 0   size: 648 x 864   new: 864
char left: 0   top: 0   size: 72 x 48   new: 48
normal: 0.636 x 1.0   new: nil
body pixel: 618 x 846   char: 68 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 6 on *SPEEDBAR*>   parent: #<window 5>
pixel left: 648   top: 0   size: 372 x 864   new: 864
char left: 72   top: 0   size: 41 x 48   new: 48
normal: 0.364 x 1.0   new: nil
body pixel: 342 x 846   char: 38 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 18  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 864   size: 1020 x 18   new: 0
char left: 0   top: 48   size: 113 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 990 x 18   char: 110 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 14  divider: 0
height header-line: 0  mode-line: 0  divider: 0

>
> If, as you said before, the behavior on Windows deviates from the one
> observed here, it would be instructive to see the corresponding frame
> dumps for the Windows build as well.

Yes, on Windows things are different.. see next post

Angelo

bug#26537: Problems with Emacs frame (GTK)

[Angelo Graziosi]

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

Il 17/04/2017 17:43, martin rudalics ha scritto:
> If, as you said before, the behavior on Windows deviates from the one
> observed here, it would be instructive to see the corresponding frame
> dumps for the Windows build as well.

 From Win10 20170327 build WITHOUT desktop file 
(win-screen-nodesktop.png, this is better from what one gets on 
GNU/Linux...):

frame pixel: 1023 x 820   cols/lines: 114 x 52   units: 9 x 16
frame text pixel: 990 x 784   cols/lines: 110 x 49
tool: 36  scroll: 17/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 6>   parent: nil
pixel left: 0   top: 36   size: 1023 x 768   new: 768
char left: 0   top: 3   size: 114 x 48   new: 48
normal: 1.0 x 1.0   new: nil

#<window 3 on *scratch*>   parent: #<window 6>
pixel left: 0   top: 36   size: 648 x 768   new: 768
char left: 0   top: 3   size: 72 x 48   new: 48
normal: 0.6334661354581673 x 1.0   new: nil
body pixel: 615 x 752   char: 68 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 16  divider: 0

#<window 7 on *SPEEDBAR*>   parent: #<window 6>
pixel left: 648   top: 36   size: 375 x 768   new: 768
char left: 72   top: 3   size: 42 x 48   new: 48
normal: 0.3665338645418327 x 1.0   new: nil
body pixel: 342 x 752   char: 38 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 16  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 804   size: 1023 x 16   new: 0
char left: 0   top: 51   size: 113 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 990 x 16   char: 110 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 0  divider: 0

---------------------------------------------------

 From Win10 20170327 build WITH desktop file (win-screen-desktop.png):

frame pixel: 1023 x 820   cols/lines: 114 x 52   units: 9 x 16
frame text pixel: 990 x 784   cols/lines: 110 x 49
tool: 36  scroll: 17/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 8>   parent: nil
pixel left: 0   top: 36   size: 1023 x 768   new: 768
char left: 0   top: 3   size: 114 x 48   new: 48
normal: 1.0 x 1.0   new: nil

#<window 3 on report_bug.txt-save>   parent: #<window 8>
pixel left: 0   top: 36   size: 756 x 768   new: 768
char left: 0   top: 3   size: 84 x 48   new: 48
normal: 0.7390029325513197 x 1.0   new: nil
body pixel: 723 x 752   char: 80 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 16  divider: 0

#<window 9 on *SPEEDBAR*>   parent: #<window 8>
pixel left: 756   top: 36   size: 267 x 768   new: 768
char left: 84   top: 3   size: 30 x 48   new: 48
normal: 0.26099706744868034 x 1.0   new: nil
body pixel: 234 x 752   char: 26 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 16  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 804   size: 1023 x 16   new: 0
char left: 0   top: 51   size: 114 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 990 x 16   char: 110 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 0  divider: 0

================================================================

I haven't 20170416 build, but this has been done just about two hours 
after..

 From Win10 20170417 build (r128952.8750a4546a) WITHOUT desktop file 
(win-screen-nodesktop.png):

frame pixel: 1023 x 820   cols/lines: 114 x 52   units: 9 x 16
frame text pixel: 990 x 784   cols/lines: 110 x 49
tool: 36  scroll: 17/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 6>   parent: nil
pixel left: 0   top: 36   size: 1023 x 768   new: 768
char left: 0   top: 3   size: 114 x 48   new: 48
normal: 1.0 x 1.0   new: 1.0

#<window 3 on *scratch*>   parent: #<window 6>
pixel left: 0   top: 36   size: 648 x 768   new: 768
char left: 0   top: 3   size: 72 x 48   new: 48
normal: 0.6334661354581673 x 1.0   new: nil
body pixel: 615 x 752   char: 68 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 16  divider: 0

#<window 7 on *SPEEDBAR*>   parent: #<window 6>
pixel left: 648   top: 36   size: 375 x 768   new: 768
char left: 72   top: 3   size: 42 x 48   new: 48
normal: 0.3665338645418327 x 1.0   new: nil
body pixel: 342 x 752   char: 38 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 16  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 804   size: 1023 x 16   new: 0
char left: 0   top: 51   size: 113 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 990 x 16   char: 110 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 0  divider: 0

-----------------------------------------------------

from Win10 20170417 build (r128952.8750a4546a) WITH desktop file 
(win-screen-desktop.png):


frame pixel: 1023 x 820   cols/lines: 114 x 52   units: 9 x 16
frame text pixel: 990 x 784   cols/lines: 110 x 49
tool: 36  scroll: 17/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 8>   parent: nil
pixel left: 0   top: 36   size: 1023 x 768   new: 768
char left: 0   top: 3   size: 114 x 48   new: 48
normal: 1.0 x 1.0   new: nil

#<window 3 on report_bug.txt-save>   parent: #<window 8>
pixel left: 0   top: 36   size: 756 x 768   new: 768
char left: 0   top: 3   size: 84 x 48   new: 48
normal: 0.7390029325513197 x 1.0   new: nil
body pixel: 723 x 752   char: 80 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 16  divider: 0

#<window 9 on *SPEEDBAR*>   parent: #<window 8>
pixel left: 756   top: 36   size: 267 x 768   new: 768
char left: 84   top: 3   size: 30 x 48   new: 48
normal: 0.26099706744868034 x 1.0   new: nil
body pixel: 234 x 752   char: 26 x 47
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 16  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 804   size: 1023 x 16   new: 0
char left: 0   top: 51   size: 114 x 1   new: 1
normal: 1.0 x 1.0   new: 0
body pixel: 990 x 16   char: 110 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 17  divider: 0
height header-line: 0  mode-line: 0  divider: 0


Ciao,
  Angelo.

[-- Attachment #2: win-screens.tar.gz --]
[-- Type: application/gzip, Size: 73407 bytes --]

bug#26537: Problems with Emacs frame (GTK)

[martin rudalics]

I looked into your init.el file now.  Your problem can be encapsulated
in the following two forms:

(setq default-frame-alist
       '(
         (width . 110) ; character
         (height . 49) ; lines
         (font . "Monospace-11") ; font
         ))

(add-hook 'emacs-startup-hook 'start-sr-speedbar)

According to its doc-string, ‘emacs-startup-hook’ is run "after loading
init files and handling the command line".  This means that you want to
split a window and give the new window a size of 30 characters.  And
afterwards you want to enlarge the window's frame to 110 characters and
change its default font and at the same time keep the window size at 30
characters.  This is (almost) asking for the impossible.

The hook you want to put ‘start-sr-speedbar’ on is ‘window-setup-hook’.
According to its doc-string:

"This is very similar to `emacs-startup-hook'.  The only difference
is that this hook runs after frame parameters have been set up in
response to any settings from your init file.  Unless this matters
to you, use `emacs-startup-hook' instead."

I'm quite confident that "it matters to you" ;-)

martin

bug#26537: Problems with Emacs frame (GTK)

[Angelo Graziosi]

Il 18/04/2017 10:07, martin rudalics ha scritto:
>
> The hook you want to put ‘start-sr-speedbar’ on is ‘window-setup-hook’.
> According to its doc-string:
>
> "This is very similar to `emacs-startup-hook'.  The only difference
> is that this hook runs after frame parameters have been set up in
> response to any settings from your init file.  Unless this matters
> to you, use `emacs-startup-hook' instead."
>
> I'm quite confident that "it matters to you" ;-)
>

Indeed! Thanks for clarification... Maybe now this can be closed.

Angelo


>

bug#26537: Problems with Emacs frame (GTK)

[martin rudalics]

 > Indeed! Thanks for clarification... Maybe now this can be closed.

Done, martin