GNU bug report logs - #4134
23.1; Problems with gtk+ >= 2.7.19

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4134 in the body.
You can then email your comments to 4134 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Ronis <ronis <at> ronispc.chem.mcgill.ca>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; Buffer Tab not being linked properly
Date: Wed, 12 Aug 2009 13:55:41 -0400

I'm working on a fortran project and am currently using emacs to edit
the Makefile, fortran source file and to do the compilation (I'm also
using it to send this bug report).   The menubar at the top has
entries that change when I switch buffers/modes; e.g., right now I see
entries like 

File Edit Options Buffers Tools Headers Mail Mailcrypt Help

Clicking on Mail or Mailcrypt doen't popup a menu.

Switching to my fortran buffer, I have


File Edit Options Buffers Tools Fortran Help

Now clicking on Fortran generates the correct menu.

Compiling the program results in a compilation buffer with 
a menubar containing

File Edit Options Buffers Tools Compile Help

Clicking on Compile gets the Fortran menu.  

Basically it seems that only the extra tab associated with the first
thing I read into emacs is present.

Is this a bug?  Any suggestions if not?

Thanks in advance.

David


In GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
 of 2009-07-30 on ronispc
Windowing system distributor `The X.Org Foundation', version 11.0.10699001
configured using `configure  'CC=/usr/bin/gcc' 'CFLAGS=-march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: en_US
  value of $LANG: C
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Fortran

Minor modes in effect:
  show-paren-mode: t
  display-time-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <C-down-mouse-1> 
M-x c o m p i l e <return> <backspace> <backspace> 
<backspace> <return> <help-echo> <down-mouse-1> <drag-mouse-1> 
<help-echo> <help-echo> <down-mouse-1> <mouse-1> C-x 
1 M-x e m a <tab> c <tab> r <tab> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> SPC r e p o <tab> r <tab> <return>

Recent messages:
Loading mailcrypt...done
PGP version set to 5.0.
Loading paren...done
For information about GNU Emacs and the GNU system, type C-h C-a.
(No files need saving)
Compilation finished
Mark set
Making completion list...
call-interactively: Text is read-only
Making completion list... [2 times]

Message #8 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: david.ronis <at> mcgill.ca
Cc: 4134 <at> debbugs.gnu.org
Subject: Re: bug#4134: 23.1; Buffer Tab not being linked properly
Date: Thu, 20 Aug 2009 20:34:28 -0400

tags 4134 moreinfo unreproducible
stop

David Ronis wrote:

> I'm working on a fortran project and am currently using emacs to
> edit the Makefile, fortran source file and to do the compilation
> (I'm also using it to send this bug report). The menubar at the top
> has entries that change when I switch buffers/modes; e.g., right now
> I see entries like
>
> File Edit Options Buffers Tools Headers Mail Mailcrypt Help
>
> Clicking on Mail or Mailcrypt doen't popup a menu.
>
> Switching to my fortran buffer, I have
>
>
> File Edit Options Buffers Tools Fortran Help
>
> Now clicking on Fortran generates the correct menu.
>
> Compiling the program results in a compilation buffer with 
> a menubar containing
>
> File Edit Options Buffers Tools Compile Help
>
> Clicking on Compile gets the Fortran menu.  


I cannot reproduce this. Can you explain how to get to this state,
starting from emacs -Q? For example, Mailcrypt is not part of Emacs.


> In GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
>  of 2009-07-30 on ronispc
[...]
> configured using `configure 'CC=/usr/bin/gcc' 'CFLAGS=-march=native
> -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops
> -fomit-frame-pointer -floop-interchange -floop-strip-mine
> -floop-block''

Wow, your Emacs goes to 11.

Message #15 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Ronis <ronis <at> ronispc.chem.mcgill.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 4134 <at> debbugs.gnu.org
Subject: Re: bug#4134: 23.1; Buffer Tab not being linked properly
Date: Thu, 20 Aug 2009 21:00:59 -0400

Hi Glen, 

Thanks for the reply.  

Here's what I did:

1. started 'emacs -Q model.f' as suggested.
2. emacs sets the buffer mode to fortran and I have the usual "Fortran"
button in the menubar.
3. compile the program using alt-x compile (then simply run make without
-k).  The window splits and I see the expected output of the
compilation.  

If I set the focus to the *compile* buffer, the "Fortran" menubar button
changes to "Compile" (as it should); however, clicking on that button
gets the fortran menu, not the compile one.

David

P.S., I've been using emacs for a long time, but where do you see
version 11?

P.S.S., mailcrypt only got called when the mailer was invoked to report
the bug.  It is normally not running.  On the other hand, "external"
packages like maxima and auctex are often in use.   The test with -Q
rules them out probably.

On Thu, 2009-08-20 at 20:34 -0400, Glenn Morris wrote:
> tags 4134 moreinfo unreproducible
> stop
> 
> David Ronis wrote:
> 
> > I'm working on a fortran project and am currently using emacs to
> > edit the Makefile, fortran source file and to do the compilation
> > (I'm also using it to send this bug report). The menubar at the top
> > has entries that change when I switch buffers/modes; e.g., right now
> > I see entries like
> >
> > File Edit Options Buffers Tools Headers Mail Mailcrypt Help
> >
> > Clicking on Mail or Mailcrypt doen't popup a menu.
> >
> > Switching to my fortran buffer, I have
> >
> >
> > File Edit Options Buffers Tools Fortran Help
> >
> > Now clicking on Fortran generates the correct menu.
> >
> > Compiling the program results in a compilation buffer with 
> > a menubar containing
> >
> > File Edit Options Buffers Tools Compile Help
> >
> > Clicking on Compile gets the Fortran menu.  
> 
> 
> I cannot reproduce this. Can you explain how to get to this state,
> starting from emacs -Q? For example, Mailcrypt is not part of Emacs.
> 
> 
> > In GNU Emacs 23.1.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
> >  of 2009-07-30 on ronispc
> [...]
> > configured using `configure 'CC=/usr/bin/gcc' 'CFLAGS=-march=native
> > -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops
> > -fomit-frame-pointer -floop-interchange -floop-strip-mine
> > -floop-block''
> 
> Wow, your Emacs goes to 11.
> 

Message #18 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: ronis <at> ronispc.chem.mcgill.ca
Cc: 4134 <at> debbugs.gnu.org
Subject: Re: bug#4134: 23.1; Buffer Tab not being linked properly
Date: Thu, 20 Aug 2009 21:18:53 -0400

David Ronis wrote:

> 1. started 'emacs -Q model.f' as suggested.
> 2. emacs sets the buffer mode to fortran and I have the usual "Fortran"
> button in the menubar.
> 3. compile the program using alt-x compile (then simply run make without
> -k).  The window splits and I see the expected output of the
> compilation.  
>
> If I set the focus to the *compile* buffer, the "Fortran" menubar button
> changes to "Compile" (as it should); however, clicking on that button
> gets the fortran menu, not the compile one.

Sorry, but for me this works as it should.

Are you somehow changing the focus when you go to select the menu bar?
What happens if you put the compilation window above the Fortran window?

> P.S., I've been using emacs for a long time, but where do you see
> version 11?

I was making fun of your CFLAGS setting. Does that really make any
measurable difference to anything, or is it just one louder?

Message #23 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Ronis <ronis <at> ronispc.chem.mcgill.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 4134 <at> debbugs.gnu.org
Subject: Re: bug#4134: 23.1; Buffer Tab not being linked properly
Date: Thu, 20 Aug 2009 21:31:07 -0400

On Thu, 2009-08-20 at 21:18 -0400, Glenn Morris wrote:
> David Ronis wrote:
> 
> > 1. started 'emacs -Q model.f' as suggested.
> > 2. emacs sets the buffer mode to fortran and I have the usual "Fortran"
> > button in the menubar.
> > 3. compile the program using alt-x compile (then simply run make without
> > -k).  The window splits and I see the expected output of the
> > compilation.  
> >
> > If I set the focus to the *compile* buffer, the "Fortran" menubar button
> > changes to "Compile" (as it should); however, clicking on that button
> > gets the fortran menu, not the compile one.
> 
> Sorry, but for me this works as it should.
> 
> Are you somehow changing the focus when you go to select the menu bar?
> What happens if you put the compilation window above the Fortran window?

I tried putting the fortran window above, below, and single-window--no
differences.

> > P.S., I've been using emacs for a long time, but where do you see
> > version 11?
> 
> I was making fun of your CFLAGS setting. Does that really make any
> measurable difference to anything, or is it just one louder?

Ahh...  I leave CFLAGS set to ultra aggressive in the environment (it
does make a difference in some of the things I do, although, very very
very unlikely to be seen in emacs).  I'm using gcc 4.4.1 which is
relatively new; perhaps this is a compiler bug.  I'll rebuild with saner
flags and see what happens.  I'll report back shortly.

Thanks for looking at this.

Message #28 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Ronis <ronis <at> ronispc.chem.mcgill.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 4134 <at> debbugs.gnu.org
Subject: Re: bug#4134: 23.1; Buffer Tab not being linked properly
Date: Thu, 20 Aug 2009 21:51:59 -0400

[Message part 1 (text/plain, inline)]

I rebuilt emacs (with CFLAGS=-O2 and --disable-debug passed to
configure).  I get the same behavior.  

Just to be sure that we're talking about the same thing, I've attached a
screenshot of the emacs window (emacs -Q bug.f) after compiling.  Notice
that I'm in the compile part of the screen and that I've activated what
should be the compile menubar entry.  The menu is that of the fortran
window.

David


On Thu, 2009-08-20 at 21:18 -0400, Glenn Morris wrote:
> David Ronis wrote:
> 
> > 1. started 'emacs -Q model.f' as suggested.
> > 2. emacs sets the buffer mode to fortran and I have the usual "Fortran"
> > button in the menubar.
> > 3. compile the program using alt-x compile (then simply run make without
> > -k).  The window splits and I see the expected output of the
> > compilation.  
> >
> > If I set the focus to the *compile* buffer, the "Fortran" menubar button
> > changes to "Compile" (as it should); however, clicking on that button
> > gets the fortran menu, not the compile one.
> 
> Sorry, but for me this works as it should.
> 
> Are you somehow changing the focus when you go to select the menu bar?
> What happens if you put the compilation window above the Fortran window?
> 
> > P.S., I've been using emacs for a long time, but where do you see
> > version 11?
> 
> I was making fun of your CFLAGS setting. Does that really make any
> measurable difference to anything, or is it just one louder?
> 

[Screenshot-emacs@montroll.chem.mcgill.ca.png (image/png, attachment)]

Message #33 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Ronis <ronis <at> ronispc.chem.mcgill.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 4134 <at> debbugs.gnu.org
Subject: Re: bug#4134: 23.1; Buffer Tab not being linked properly
Date: Thu, 20 Aug 2009 22:21:50 -0400

I figured out what the problem is.  I'm running slackware 12.2 which no
longer supports gnome.  To have gnome, I use the garnome build system
(which basically installs everything gnome needs into a separate tree).
Since, some (usually older) components exist in the system, garnome uses
environment variables like PATH and LD_LIBRARY_PATH to make sure that
the garnome versions of various libraries, programs are found first.

When I build basic system utilities (emacs is one of them), I break out
of garnome (by unsetting environment variables) and build/install.  As
such emacs links against slackware's libs.  Even so, running in the
garnome environment still worked, until now.  In fact, my problem goes
away if I run in the garnome-free environment, and I can hack a fix, by
calling emacs from a script.

Since I'm usually running gnome, I rebuilt emacs in the garnome
environment.  The build completed, but the resulting emacs has the
problem.  My bet is that one of the more recent gnome libs (probably gtk
+) is at fault.  I'm using gtk+2.17.8 here.  

Any suggestions how to pin this down?  I build garnome with -O2 -g so
debugging sessions are possible.

Here's  a list of the garnome versions used by emacs:

	libgtk-x11-2.0.so.0 => /opt/gnome/lib/libgtk-x11-2.0.so.0 (0xb7b19000)
	libgdk-x11-2.0.so.0 => /opt/gnome/lib/libgdk-x11-2.0.so.0 (0xb7a6d000)
	libatk-1.0.so.0 => /opt/gnome/lib/libatk-1.0.so.0 (0xb7a50000)
	libpangoft2-1.0.so.0 => /opt/gnome/lib/libpangoft2-1.0.so.0
(0xb7a25000)
	libgdk_pixbuf-2.0.so.0 => /opt/gnome/lib/libgdk_pixbuf-2.0.so.0
(0xb7a0a000)
	libpangocairo-1.0.so.0 => /opt/gnome/lib/libpangocairo-1.0.so.0
(0xb79a9000)
	libgio-2.0.so.0 => /opt/gnome/lib/libgio-2.0.so.0 (0xb78fd000)
	libXcursor.so.1 => /opt/gnome/lib/libXcursor.so.1 (0xb78c7000)
	libXrender.so.1 => /opt/gnome/lib/libXrender.so.1 (0xb78b9000)
	libcairo.so.2 => /opt/gnome/lib/libcairo.so.2 (0xb7834000)
	libpango-1.0.so.0 => /opt/gnome/lib/libpango-1.0.so.0 (0xb768e000)
	libfreetype.so.6 => /opt/gnome/lib/libfreetype.so.6 (0xb7614000)
	libfontconfig.so.1 => /opt/gnome/lib/libfontconfig.so.1 (0xb75cc000)
	libgobject-2.0.so.0 => /opt/gnome/lib/libgobject-2.0.so.0 (0xb7588000)
	libgmodule-2.0.so.0 => /opt/gnome/lib/libgmodule-2.0.so.0 (0xb7584000)
	libglib-2.0.so.0 => /opt/gnome/lib/libglib-2.0.so.0 (0xb74a4000)
	libXft.so.2 => /opt/gnome/lib/libXft.so.2 (0xb7385000)
	librsvg-2.so.2 => /opt/gnome/lib/librsvg-2.so.2 (0xb7289000)
	libdbus-1.so.3 => /opt/gnome/lib/libdbus-1.so.3 (0xb7230000)
	libpixman-1.so.0 => /opt/garnome-svn-2.27/lib/libpixman-1.so.0
(0xb6f4b000)
	libglitz.so.1 => /opt/garnome-svn-2.27/lib/libglitz.so.1 (0xb6f23000)
	libexpat.so.1 => /opt/garnome-svn-2.27/lib/libexpat.so.1 (0xb6ec7000)
	libgsf-1.so.114 => /opt/garnome-svn-2.27/lib/libgsf-1.so.114
(0xb6e81000)
	libcroco-0.6.so.3 => /opt/garnome-svn-2.27/lib/libcroco-0.6.so.3
(0xb6e35000)
	libxml2.so.2 => /opt/garnome-svn-2.27/lib/libxml2.so.2 (0xb6cfa000)

Message #38 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: ronis <at> ronispc.chem.mcgill.ca
Cc: 4134 <at> debbugs.gnu.org
Subject: Re: bug#4134: 23.1; Buffer Tab not being linked properly
Date: Sat, 22 Aug 2009 19:06:38 -0400

David Ronis wrote:

> When I build basic system utilities (emacs is one of them), I break out
> of garnome (by unsetting environment variables) and build/install.  As
> such emacs links against slackware's libs.  Even so, running in the
> garnome environment still worked, until now.  In fact, my problem goes
> away if I run in the garnome-free environment, and I can hack a fix, by
> calling emacs from a script.

That's probably what I'd do.

> Since I'm usually running gnome, I rebuilt emacs in the garnome
> environment.  The build completed, but the resulting emacs has the
> problem.  My bet is that one of the more recent gnome libs (probably gtk
> +) is at fault.  I'm using gtk+2.17.8 here.  

AFAIK, there should be no problems with recent versions of gtk libraries.

> Any suggestions how to pin this down? 

Sorry, no idea. Maybe someone else on this list can help...

Message #43 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David Ronis <ronis <at> ronispc.chem.mcgill.ca>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 4134 <at> debbugs.gnu.org
Subject: [Fwd: [Bug 593249] emacs and acroread don't work properly after
 upgrading to 2.17.9]
Date: Thu, 27 Aug 2009 11:58:02 -0400

[Message part 1 (text/plain, inline)]

Turns out the problem is in gtk+.  I've filed a bug report and this is
the last (relevant) comment on the bug.

David

[Message part 2 (message/rfc822, inline)]

From: gtk+ (bugzilla.gnome.org) <bugzilla <at> gnome.org>
To: david.ronis <at> mcgill.ca
Subject: [Bug 593249] emacs and acroread don't work properly after
 upgrading to 2.17.9
Date: Thu, 27 Aug 2009 11:34:17 +0000 (UTC)

http://bugzilla.gnome.org/show_bug.cgi?id=593249



--- Comment #3 from Alexander Larsson <alexl <at> redhat.com> 2009-08-27 11:34:14 UTC ---
For the emacs thing, I can reproduce this here, but emacs does some pretty
weird things in its Gtk+ integration that can conflict quite a lot with the new
client-side window stuff in the later Gtk+.

Running with GDK_NATIVE_WINDOWS=1 in gtk+ >= 2.17.9 fixes this issue, although
setting that in emacs may not be a good idea as it will propagate to apps
launched by emacs. Instead I would recommend adding some code to emacs that
calls gdk_x11_drawable_get_xid() on all "toplevel" Gtk+ widgets they put in the
buffer window. This will ensure these windows get their own X window and should
be totally backwards compat and safe on older versions of Gtk+.

-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug.

Message #46 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: ronis <at> ronispc.chem.mcgill.ca
Cc: 4134 <at> debbugs.gnu.org,
        Jan Djärv
 <jan.h.d <at> swipnet.se>
Subject: Re: [Fwd: [Bug 593249] emacs and acroread don't work properly after upgrading to 2.17.9]
Date: Thu, 27 Aug 2009 18:59:20 -0400

retitle 4134 23.1; Problems with gtk+ >= 2.7.19
stop

David Ronis wrote:

> Turns out the problem is in gtk+.  I've filed a bug report and this is
> the last (relevant) comment on the bug.

Thanks for forwarding this information. Hopefully it will be useful to
those Emacs developers who understand these things (Jan?).

> http://bugzilla.gnome.org/show_bug.cgi?id=593249
[...]
> --- Comment #3 from Alexander Larsson <alexl <at> redhat.com> 2009-08-27
[...]
> Instead I would recommend adding some code to emacs that calls
> gdk_x11_drawable_get_xid() on all "toplevel" Gtk+ widgets they put
> in the buffer window. This will ensure these windows get their own X
> window and should be totally backwards compat and safe on older
> versions of Gtk+.

Message #53 received at 4134 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Glenn Morris <rgm <at> gnu.org>
Cc: ronis <at> ronispc.chem.mcgill.ca, 4134 <at> debbugs.gnu.org
Subject: Re: [Fwd: [Bug 593249] emacs and acroread don't work properly after
 upgrading to 2.17.9]
Date: Sun, 30 Aug 2009 12:36:14 +0200

Glenn Morris skrev:
> retitle 4134 23.1; Problems with gtk+ >= 2.7.19
> stop
> 
> David Ronis wrote:
> 
>> Turns out the problem is in gtk+.  I've filed a bug report and this is
>> the last (relevant) comment on the bug.
> 
> Thanks for forwarding this information. Hopefully it will be useful to
> those Emacs developers who understand these things (Jan?).
> 
>> http://bugzilla.gnome.org/show_bug.cgi?id=593249
> [...]
>> --- Comment #3 from Alexander Larsson <alexl <at> redhat.com> 2009-08-27
> [...]
>> Instead I would recommend adding some code to emacs that calls
>> gdk_x11_drawable_get_xid() on all "toplevel" Gtk+ widgets they put
>> in the buffer window. This will ensure these windows get their own X
>> window and should be totally backwards compat and safe on older
>> versions of Gtk+.

This client side windows Gtk+ is introducing in 2.17 assumes you only do Gtk+ 
calls.  But Emacs does a lot of pure X11 calls on the X11 windows created by 
Gtk+.  So eihter Emacs must go pure Gtk+ for the Gtk+ build, or we do a 
workaround.  The workaround seems most likely for now.

I'll get on it when I find some time.

	Jan D.

Previous Next

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