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

["Jan Djärv" <jan.h.d@swipnet.se>]

6 sep 2012 kl. 14:31 skrev Robert Dallas Gray <mail@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.