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

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

[Robert Dallas Gray]

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)

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

[Glenn Morris]

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.

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

[Jan Djärv]

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.

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

[Glenn Morris]

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

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

[Jan Djärv]

Hello.

12 sep 2012 kl. 20:22 skrev Glenn Morris <rgm@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.

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

[Glenn Morris]

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.

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

[Jan Djärv]

Hello. 

This is fixed in the trunk.


     Jan D.

12 sep 2012 kl. 22:41 skrev Glenn Morris <rgm@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.

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

[Andy Moreton]

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