GNU bug report logs - #12368
24.1; x-parse-geometry broken in Emacs 24.1

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 12368 in the body.
You can then email your comments to 12368 AT debbugs.gnu.org in the normal way.

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

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Robert Dallas Gray <mail <at> robertdallasgray.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1; x-parse-geometry broken in Emacs 24.1
Date: Thu, 6 Sep 2012 13:31:11 +0100

emacs -Q
M-:
(x-parse-geometry "80x40+5+10")

Expected result: ((height . 40) (width . 80) (top . 10) (left . 5))
Actual result:   ((top . 80)) 


In GNU Emacs 24.1.1 (x86_64-apple-darwin11.4.0, NS apple-appkit-1138.47)
of 2012-09-03 on pud.default
Windowing system distributor `Apple', version 10.3.1138
Configured using:
`configure '--prefix=/usr/local/Cellar/emacs/24.1' '--without-dbus'
'--enable-locallisppath=/usr/local/share/emacs/site-lisp'
'--infodir=/usr/local/Cellar/emacs/24.1/share/info/emacs' '--with-ns'
'--disable-ns-self-contained' 'CC=/usr/bin/clang' 'CFLAGS=-Os -w -pipe
-march=native -Qunused-arguments -mmacosx-version-min=10.7'
'LDFLAGS=-L/usr/local/lib''

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: nil
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

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

Recent input:
ESC [ ? 1 ; 2 c ESC : ( x - p a r s e - g e o m e t 
r e DEL y SPC " 3 5 x 2 5 + 0 + 0 " ) RET ESC x r e 
p o r t SPC DEL - e TAB RET

Recent messages:
("/usr/local/Cellar/emacs/24.1/bin/emacs")
For information about GNU Emacs and the GNU system, type C-h C-a.
((top . 35))

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process ns multi-tty
emacs)

Message #8 received at 12368 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Robert Dallas Gray <mail <at> robertdallasgray.com>
Cc: 12368 <at> debbugs.gnu.org
Subject: Re: bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
Date: Thu, 06 Sep 2012 12:57:28 -0400

Robert Dallas Gray wrote:

> emacs -Q
> M-:
> (x-parse-geometry "80x40+5+10")
>
> Expected result: ((height . 40) (width . 80) (top . 10) (left . 5))

Works fine on GNU/Linux in 24.1.

> Actual result:   ((top . 80)) 
>
> In GNU Emacs 24.1.1 (x86_64-apple-darwin11.4.0, NS apple-appkit-1138.47)

C-h f x-parse-geometry:

   On Nextstep, this just calls `ns-parse-geometry'.

C-h f ns-parse-geometry:

   Parse a Nextstep-style geometry string GEOM.

Why this needs to be different on this platform I do not know, but it is.

Message #11 received at 12368 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Robert Dallas Gray <mail <at> robertdallasgray.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 12368 <at> debbugs.gnu.org
Subject: Re: bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
Date: Sat, 8 Sep 2012 15:29:46 +0200

6 sep 2012 kl. 14:31 skrev Robert Dallas Gray <mail <at> robertdallasgray.com>:

> emacs -Q
> M-:
> (x-parse-geometry "80x40+5+10")
> 
> Expected result: ((height . 40) (width . 80) (top . 10) (left . 5))
> Actual result:   ((top . 80)) 


Glenn Morris wrote:

> 
> C-h f x-parse-geometry:
> 
>    On Nextstep, this just calls `ns-parse-geometry'.
> 
> C-h f ns-parse-geometry:
> 
>    Parse a Nextstep-style geometry string GEOM.
> 
> Why this needs to be different on this platform I do not know, but it is.

x-parse-geometry (non-NS variant) calls XParseGeometry.  This may not be available.  But the W32-prt has an implementation.

It seems as ns-parse-geometry expects "top left with height", i.e.:

(x-parse-geometry "10 5 80 40")
((top . 10) (left . 5) (height . 80) (width . 40))

I don't know where this type of geometry is specified, but we could support both (if there is a space in the string, it is NS-style, if there is a +, -, x orX, it is X-style).

We could move the W32-version of XParseGeometry somewhere common (where?) and use that.
Or we can rewrite x-parse-geometry in lisp.

Suggestions?

	Jan D.

Message #14 received at 12368 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Robert Dallas Gray <mail <at> robertdallasgray.com>, 12368 <at> debbugs.gnu.org
Subject: Re: bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
Date: Wed, 12 Sep 2012 14:22:32 -0400

Jan Djärv wrote:

> x-parse-geometry (non-NS variant) calls XParseGeometry. This may not
> be available. But the W32-prt has an implementation.
>
> It seems as ns-parse-geometry expects "top left with height", i.e.:
>
> (x-parse-geometry "10 5 80 40")
> ((top . 10) (left . 5) (height . 80) (width . 40))
>
> I don't know where this type of geometry is specified, but we could
> support both (if there is a space in the string, it is NS-style, if
> there is a +, -, x orX, it is X-style).
>
> We could move the W32-version of XParseGeometry somewhere common
> (where?) and use that. Or we can rewrite x-parse-geometry in lisp.
>
> Suggestions?

I don't know...
At first I was going to say, rewrite x-parse-geometry in Lisp sounds
simple, especially if you want to handle both style of geometry.
But then since XParseGeometry is standard in X11 and already
reimplemented in w32xfns.c, maybe it's simpler just to use that.
And set_frame_size calls XParseGeometry from C as well (so how does that
work on NS? I see nsfns.m has a stub definition as well).

Message #17 received at 12368 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Robert Dallas Gray <mail <at> robertdallasgray.com>, 12368 <at> debbugs.gnu.org
Subject: Re: bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
Date: Wed, 12 Sep 2012 22:30:33 +0200

Hello.

12 sep 2012 kl. 20:22 skrev Glenn Morris <rgm <at> gnu.org>:

> Jan Djärv wrote:
> 
>> x-parse-geometry (non-NS variant) calls XParseGeometry. This may not
>> be available. But the W32-prt has an implementation.
>> 
>> It seems as ns-parse-geometry expects "top left with height", i.e.:
>> 
>> (x-parse-geometry "10 5 80 40")
>> ((top . 10) (left . 5) (height . 80) (width . 40))
>> 
>> I don't know where this type of geometry is specified, but we could
>> support both (if there is a space in the string, it is NS-style, if
>> there is a +, -, x orX, it is X-style).
>> 
>> We could move the W32-version of XParseGeometry somewhere common
>> (where?) and use that. Or we can rewrite x-parse-geometry in lisp.
>> 
>> Suggestions?
> 
> I don't know...
> At first I was going to say, rewrite x-parse-geometry in Lisp sounds
> simple, especially if you want to handle both style of geometry.
> But then since XParseGeometry is standard in X11 and already
> reimplemented in w32xfns.c, maybe it's simpler just to use that.

Ok, I can move it to frame.c with suitable #ifdefs around it.

> And set_frame_size calls XParseGeometry from C as well (so how does that
> work on NS? I see nsfns.m has a stub definition as well).

I don't see how set_frame_size calls XParseGeometry.  The only calls I see are in Fx_parse_geometry and in widget.c (Xt only).

	Jan D.

Message #20 received at 12368 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: Robert Dallas Gray <mail <at> robertdallasgray.com>, 12368 <at> debbugs.gnu.org
Subject: Re: bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
Date: Wed, 12 Sep 2012 16:41:50 -0400

Jan Djärv wrote:

>> And set_frame_size calls XParseGeometry from C as well (so how does that
>> work on NS? I see nsfns.m has a stub definition as well).
>
> I don't see how set_frame_size calls XParseGeometry. The only calls I
> see are in Fx_parse_geometry and in widget.c (Xt only).

The widget.c one is in a function called set_frame_size. I missed that
it was not the "real" set_frame_size.

Message #25 received at 12368-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Robert Dallas Gray <mail <at> robertdallasgray.com>,
	"12368-done <at> debbugs.gnu.org" <12368-done <at> debbugs.gnu.org>
Subject: Re: bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
Date: Wed, 19 Sep 2012 08:51:03 +0200

Hello. 

This is fixed in the trunk.


     Jan D.

12 sep 2012 kl. 22:41 skrev Glenn Morris <rgm <at> gnu.org>:

> Jan Djärv wrote:
> 
>>> And set_frame_size calls XParseGeometry from C as well (so how does that
>>> work on NS? I see nsfns.m has a stub definition as well).
>> 
>> I don't see how set_frame_size calls XParseGeometry. The only calls I
>> see are in Fx_parse_geometry and in widget.c (Xt only).
> 
> The widget.c one is in a function called set_frame_size. I missed that
> it was not the "real" set_frame_size.

Message #28 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
Date: Wed, 19 Sep 2012 22:21:18 +0100

On Wed 19 Sep 2012, Jan Djärv wrote:

> Hello. 
>
> This is fixed in the trunk.

Except that r110099 then changed it and broke the Windows build:

gcc -I. -c -gdwarf-2 -g3  -DEMACSDEBUG -fno-crossjumping  -IC:/emacs/devel/libxml2-2.7.8/include/libxml2 -IC:/emacs/devel/giflib-4.1.4-1/include -IC:/emacs/devel/jpeg-6b-4/include -IC:/emacs/devel/tiff-3.8.2-1/include -IC:/emacs/devel/libpng-1.4.3-1/include -IC:/emacs/devel/xpm-3.5.1-1/include -IC:/emacs/devel/xpm-3.5.1-1/src/xpm/3.5.1/libXpm-3.5.1-src/lib -IC:/emacs/devel/zlib-1.2.5-2/include -Demacs=1 -I../lib -I../nt/inc -DHAVE_NTGUI=1 -DUSE_CRT_DLL=1 -o oo/i386/frame.o frame.c
frame.c:3915:1: error: static declaration of 'XParseGeometry' follows non-static declaration
w32gui.h:121:12: note: previous declaration of 'XParseGeometry' was here

Could someone please commit the obvious cleanup.

    AndyM

Previous Next

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