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

Previous Next

Full log

View this message in rfc822 format

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: 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.

Previous Next

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