GNU bug report logs -
#12733
24.2.50; Disabling menu bar doesn't resize frame correctly --with-x-toolkit=motif
Previous Next
Reported by: Ulrich Mueller <ulm <at> gentoo.org>
Date: Thu, 25 Oct 2012 15:19:01 UTC
Severity: normal
Found in version 24.2.50
Done: Jan Djärv <jan.h.d <at> swipnet.se>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12733 in the body.
You can then email your comments to 12733 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Thu, 25 Oct 2012 15:19:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Ulrich Mueller <ulm <at> gentoo.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 25 Oct 2012 15:19:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
With Emacs from BZR (revision 110662) linked against the Motif toolkit
(version 2.3.4), I observe that after disabling the menu bar, the
frame doesn't have the correct height. The result is that the modeline
and the minibuffer are no longer visible.
Steps to reproduce:
$ emacs -Q
;; Lisp Interaction Mode:
(frame-pixel-height)
608
(frame-height)
38
(menu-bar-mode -1)
nil
;; At this point, the X window shrinks by the height of the menu bar.
;; However, the bottom of the frame contents (containing modeline and
;; minibuffer) are no longer visible.
(frame-pixel-height)
608
;; Number of lines is _larger_ than before:
(frame-height)
40
In GNU Emacs 24.2.50.1 (x86_64-pc-linux-gnu, Motif Version 2.3.4)
of 2012-10-25 on juno
Bzr revision: eggert <at> cs.ucla.edu-20121025043539-ywusszr9cgklw9p7
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description: Gentoo Base System release 2.2
Configured using:
`configure '--prefix=/usr' '--build=x86_64-pc-linux-gnu'
'--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc'
'--localstatedir=/var/lib' '--libdir=/usr/lib64'
'--disable-dependency-tracking' '--program-suffix=-emacs-24-vcs'
'--program-transform-name=s/emacs-[0-9].*/emacs-24-vcs/'
'--infodir=/usr/share/info/emacs-24-vcs'
'--enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp'
'--with-crt-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64'
'--with-gameuser=games' '--without-compress-info' '--without-hesiod'
'--without-kerberos' '--without-kerberos5' '--with-gpm' '--with-dbus'
'--without-gnutls' '--without-xml2' '--without-selinux'
'--without-wide-int' '--with-sound' '--with-x' '--without-ns'
'--without-gconf' '--without-gsettings' '--without-toolkit-scroll-bars'
'--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff'
'--with-xpm' '--with-imagemagick' '--with-xft' '--without-libotf'
'--without-m17n-flt' '--with-x-toolkit=motif'
'GENTOO_PACKAGE=app-editors/emacs-vcs-24.2.9999' 'EBZR_BRANCH=trunk'
'EBZR_REVNO=110662' 'build_alias=x86_64-pc-linux-gnu'
'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=core2 -ggdb -O2 -pipe
-O2' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed' 'CPPFLAGS=''
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Mon, 29 Oct 2012 11:56:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 12733 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 25 Oct 2012, Ulrich Mueller wrote:
> With Emacs from BZR (revision 110662) linked against the Motif toolkit
> (version 2.3.4), I observe that after disabling the menu bar, the
> frame doesn't have the correct height. The result is that the modeline
> and the minibuffer are no longer visible.
> Steps to reproduce:
> $ emacs -Q
> ;; Lisp Interaction Mode:
> (frame-pixel-height)
> 608
In fact, there's already an inconsistency here. The documentation of
frame-pixel-height says:
With the Motif or Lucid toolkits, it also includes the tool bar
(but not the menu bar).
However, if I measure the height on my screen, it is 608 pixels in
total, i.e. including _both_ the tool bar and the menu bar. (I see the
same inconsistency if configured --with-x-toolkit=lucid, BTW.)
Is it an error in the code or in the documentation?
> (frame-height)
> 38
> (menu-bar-mode -1)
> nil
> ;; At this point, the X window shrinks by the height of the menu bar.
> ;; However, the bottom of the frame contents (containing modeline and
> ;; minibuffer) are no longer visible.
> (frame-pixel-height)
> 608
This value is definitely wrong. Measured height is only 572 pixels.
> ;; Number of lines is _larger_ than before:
> (frame-height)
> 40
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Tue, 30 Oct 2012 18:46:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 12733 <at> debbugs.gnu.org (full text, mbox):
Hello.
29 okt 2012 kl. 12:53 skrev Ulrich Mueller <ulm <at> gentoo.org>:
>>>>>> On Thu, 25 Oct 2012, Ulrich Mueller wrote:
>
>> With Emacs from BZR (revision 110662) linked against the Motif toolkit
>> (version 2.3.4), I observe that after disabling the menu bar, the
>> frame doesn't have the correct height. The result is that the modeline
>> and the minibuffer are no longer visible.
>
>> Steps to reproduce:
>
>> $ emacs -Q
>
>> ;; Lisp Interaction Mode:
>> (frame-pixel-height)
>> 608
>
> In fact, there's already an inconsistency here. The documentation of
> frame-pixel-height says:
>
> With the Motif or Lucid toolkits, it also includes the tool bar
> (but not the menu bar).
>
> However, if I measure the height on my screen, it is 608 pixels in
> total, i.e. including _both_ the tool bar and the menu bar. (I see the
> same inconsistency if configured --with-x-toolkit=lucid, BTW.)
>
> Is it an error in the code or in the documentation?
I've fixed the documentation.
>
>> (frame-height)
>> 38
>> (menu-bar-mode -1)
>> nil
>> ;; At this point, the X window shrinks by the height of the menu bar.
>> ;; However, the bottom of the frame contents (containing modeline and
>> ;; minibuffer) are no longer visible.
Do they appear if you resize the frame a bit?
>
>> (frame-pixel-height)
>> 608
>
> This value is definitely wrong. Measured height is only 572 pixels.
>
>> ;; Number of lines is _larger_ than before:
>> (frame-height)
>> 40
I can't reproduce the problem. It sounds as Emacs does not get the resize event from your window manager. Can you try with another window manager? What are you using now?
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Tue, 30 Oct 2012 20:14:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 12733 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 30 Oct 2012, Jan Djärv wrote:
>>> With Emacs from BZR (revision 110662) linked against the Motif toolkit
>>> (version 2.3.4), I observe that after disabling the menu bar, the
>>> frame doesn't have the correct height. The result is that the modeline
>>> and the minibuffer are no longer visible.
>>> (menu-bar-mode -1)
>>> nil
>>> ;; At this point, the X window shrinks by the height of the menu bar.
>>> ;; However, the bottom of the frame contents (containing modeline and
>>> ;; minibuffer) are no longer visible.
> Do they appear if you resize the frame a bit?
Yes, they do appear.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Tue, 30 Oct 2012 21:12:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 12733 <at> debbugs.gnu.org (full text, mbox):
Hello.
30 okt 2012 kl. 21:10 skrev Ulrich Mueller <ulm <at> gentoo.org>:
>>>>>> On Tue, 30 Oct 2012, Jan Djärv wrote:
>
>>>> With Emacs from BZR (revision 110662) linked against the Motif toolkit
>>>> (version 2.3.4), I observe that after disabling the menu bar, the
>>>> frame doesn't have the correct height. The result is that the modeline
>>>> and the minibuffer are no longer visible.
>
>>>> (menu-bar-mode -1)
>>>> nil
>>>> ;; At this point, the X window shrinks by the height of the menu bar.
>>>> ;; However, the bottom of the frame contents (containing modeline and
>>>> ;; minibuffer) are no longer visible.
>
>> Do they appear if you resize the frame a bit?
>
> Yes, they do appear.
So the size calculation is sound, Emacs is either not getting resize events or does not understand them. This is usually window manager related.
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Wed, 31 Oct 2012 10:30:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 12733 <at> debbugs.gnu.org (full text, mbox):
> So the size calculation is sound, Emacs is either not getting resize
> events or does not understand them. This is usually window manager
> related.
Are you sure that we don't miss calling the display engine here after
updating the frame parameters?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Thu, 01 Nov 2012 07:25:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 12733 <at> debbugs.gnu.org (full text, mbox):
Hello.
31 okt 2012 kl. 11:26 skrev martin rudalics <rudalics <at> gmx.at>:
> > So the size calculation is sound, Emacs is either not getting resize
> > events or does not understand them. This is usually window manager
> > related.
>
> Are you sure that we don't miss calling the display engine here after
> updating the frame parameters?
There is no calling the display engine in this case, there is just setting the frame garbaged and adjusting the frame size.
Given the fact that I can't reproduce it suggests it is working for some cases at least. But the exact environment of the reporter is not known, we don't know which window manager he uses. So we probably can't reproduce this util we know that.
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Thu, 01 Nov 2012 09:16:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 12733 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 1 Nov 2012, Jan Djärv wrote:
> There is no calling the display engine in this case, there is just
> setting the frame garbaged and adjusting the frame size.
> Given the fact that I can't reproduce it suggests it is working for
> some cases at least. But the exact environment of the reporter is
> not known, we don't know which window manager he uses. So we
> probably can't reproduce this util we know that.
Window manager here is xfwm4 version 4.10.0.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Thu, 01 Nov 2012 13:54:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 12733 <at> debbugs.gnu.org (full text, mbox):
> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Thu, 1 Nov 2012 08:22:13 +0100
> Cc: 12733 <at> debbugs.gnu.org, Ulrich Mueller <ulm <at> gentoo.org>
>
> > Are you sure that we don't miss calling the display engine here after
> > updating the frame parameters?
>
> There is no calling the display engine in this case, there is just setting the frame garbaged and adjusting the frame size.
Which will cause the display engine reallocate the glyph matrices and
redraw everything at the next redisplay opportunity.
Reply sent
to
Jan Djärv <jan.h.d <at> swipnet.se>
:
You have taken responsibility.
(Fri, 02 Nov 2012 17:29:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Ulrich Mueller <ulm <at> gentoo.org>
:
bug acknowledged by developer.
(Fri, 02 Nov 2012 17:29:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 12733-done <at> debbugs.gnu.org (full text, mbox):
Hello.
1 nov 2012 kl. 10:12 skrev Ulrich Mueller <ulm <at> gentoo.org>:
>>>>>> On Thu, 1 Nov 2012, Jan Djärv wrote:
>
>> There is no calling the display engine in this case, there is just
>> setting the frame garbaged and adjusting the frame size.
>
>> Given the fact that I can't reproduce it suggests it is working for
>> some cases at least. But the exact environment of the reporter is
>> not known, we don't know which window manager he uses. So we
>> probably can't reproduce this util we know that.
>
> Window manager here is xfwm4 version 4.10.0.
It is reproducible with that WM. My guess is that Xt filters out the ConfigureNotify from xfwm4 because of a bad timestamp or serial.
I have checked in a fix in the trunk.
Jan D.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Fri, 02 Nov 2012 18:48:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 12733-done <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 2 Nov 2012, Jan Djärv wrote:
>> Window manager here is xfwm4 version 4.10.0.
> It is reproducible with that WM. My guess is that Xt filters out
> the ConfigureNotify from xfwm4 because of a bad timestamp or serial.
> I have checked in a fix in the trunk.
Thank you. I can confirm that I don't see the problem in the trunk
(revno 110771) any more.
Since this was a regression from Emacs 23, I wonder if the fix
wouldn't qualify for the emacs-24 branch?
Ulrich
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12733
; Package
emacs
.
(Sat, 03 Nov 2012 11:42:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 12733-done <at> debbugs.gnu.org (full text, mbox):
Hello.
2 nov 2012 kl. 19:44 skrev Ulrich Mueller <ulm <at> gentoo.org>:
>>>>>> On Fri, 2 Nov 2012, Jan Djärv wrote:
>
>>> Window manager here is xfwm4 version 4.10.0.
>
>> It is reproducible with that WM. My guess is that Xt filters out
>> the ConfigureNotify from xfwm4 because of a bad timestamp or serial.
>
>> I have checked in a fix in the trunk.
>
> Thank you. I can confirm that I don't see the problem in the trunk
> (revno 110771) any more.
>
> Since this was a regression from Emacs 23, I wonder if the fix
> wouldn't qualify for the emacs-24 branch?
I put it there.
Jan D.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 01 Dec 2012 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 156 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.