Subject: bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1

From: Jan Djärv <[email-masked]>
Date: Sat, 8 Sep 2012 15:29:46 +0200

6 sep 2012 kl. 14:31 skrev Robert Dallas Gray <[email-masked]>:

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