GNU bug report logs - #26537
Problems with Emacs frame (GTK)

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Angelo Graziosi <angelo.graziosi <at> alice.it>, 26537 <at> debbugs.gnu.org
Subject: bug#26537: Problems with Emacs frame (GTK)
Date: Mon, 17 Apr 2017 10:17:17 +0200

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.