bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)


From: David Fussner
Subject: bug#44794: 28.0.50; Frame creation broken with (tool-bar-mode -1)
Date: Sun, 13 Dec 2020 18:17:41 +0000

I have an improved analysis of the bug.

Stefan's commit did _not_ cause the bug, merely uncovered it. Kwin was
setting a minimum frame size for frames that matched the original
initial frame title "emacs@system_name", so when Stefan changed that
to "GNU Emacs at system_name" kwin no longer resized the frame, and
that seems to be the root of the problem. (I haven't any idea whatever
where that kwin setting came from.)

Having eliminated the kwin setting, I was able to bisect again and
found that 2c0cd9008 was the culprit, which was J. Scott Berg's fix
for bug #44002 involving the vcxsrv X server on Windows. Reverting
that commit fixes my issue. Stepping through the code suggests that
his extra test in xterm.c (l. 8950) is preventing a resize event when
creating a new frame on my machine when tool-bar-mode is off. With
that mode on, the resize event still occurs, and new frames are
created normally.

I've done a little testing trying to find workarounds, so I'll include
a summary here in case that might help:

To reproduce the bug, I can simply start from ./emacs -Q, M-x
tool-bar-mode rtn, C-x 5 b rtn.

./configure --with-x-toolkit=lucid : works well (i.e., cairo build w/o
gtk works fine)
./configure --without-cairo : works well (i.e., w/ gtk3 and w/o cairo)
./configure --with-x-toolkit=gtk2 : shows same bug
./configure --with-x-toolkit=gtk2 --without-cairo : works well

So perhaps some interaction between cairo and gtk, possibly specific
to my library versions, seems to stop presentation of the main text
widget and also the mode line and minibuffer on new frames when no
tool bar is present. I should add that when the invisible buffer text
contains, say, a URL, rolling over it with the mouse still reveals the
tool tip describing the link, and clicking there does open the link in
the window, though the main text widget of that window remains
visually empty until I resize the frame.

Please let me know if I can provide any additional information.

David.

On Sun, 22 Nov 2020 at 21:47, David Fussner <dfussner@googlemail.com> wrote:
>
> As no one else seems to be able to reproduce this bug, I thought I
> would give a fuller list of the symptoms I've seen when using various
> set-ups in my .emacs file, in case that might help.
>
> If in addition to turning off the tool bar you add:
>
> (add-to-list 'default-frame-alist
>                 '(height . 30)
>                 '(font . "Luxi Mono-16"))
>
> Then the initial frame shows the splash page just fine, and all looks
> well. After C-x 5 b return then the *scratch* buffer pops up with all
> the problems described in the initial report: nothing visible in the
> main window and no mini-buffer, either.
>
> If you make the height too big for the screen, in my case with such a
> big font I set it to 33, then the initial frame shows the splash page
> just fine and is as tall as the screen allows. After C-x 5 b return
> then the *scratch* buffer does appear, with text and mini-buffer
> intact, only the second frame is about two-thirds the correct height.
>
> After Eli's suggestion above about the WM I did try shutting down KDE
> and running xfce4, with exactly the same results as with KDE, as far
> as I could tell.
>
> Thanks again to you both for all your help.
>
> David.
>
> On Sun, 22 Nov 2020 at 20:50, David Fussner <dfussner@googlemail.com> wrote:
> >
> > I'm sorry to report it didn't help (aside from modifying what appears
> > in the title bar).
> >
> > On Sun, 22 Nov 2020 at 19:59, Eli Zaretskii <eliz@gnu.org> wrote:
> > >
> > > > From: David Fussner <dfussner@googlemail.com>
> > > > Date: Sun, 22 Nov 2020 19:23:16 +0000
> > > > Cc: Eli Zaretskii <eliz@gnu.org>, 44794@debbugs.gnu.org
> > > >
> > > > Thanks for the tip -- it says "GNU Emacs at newfont" when it first
> > > > comes up, then prepends the buffer name to that later.
> > >
> > > What happens if you change this:
> > >
> > >   Lisp_Object icon_title_name_format
> > >     = pure_list (empty_unibyte_string,
> > >                  build_pure_c_string ("%b - GNU Emacs at "),
> > >                  intern_c_string ("system-name"));
> > >
> > > to say this instead:
> > >
> > >   Lisp_Object icon_title_name_format
> > >     = pure_list (empty_unibyte_string,
> > >                  build_pure_c_string ("GNU Emacs at "),
> > >                  intern_c_string ("system-name"));
> > >
> > > This code is in xdisp.c.  The change I propose removes the "%b - "
> > > part from the argument to build_pure_c_string.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]