* bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
@ 2012-09-06 12:31 Robert Dallas Gray
2012-09-06 16:57 ` Glenn Morris
2012-09-08 13:29 ` Jan Djärv
0 siblings, 2 replies; 8+ messages in thread
From: Robert Dallas Gray @ 2012-09-06 12:31 UTC (permalink / raw)
To: 12368
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)
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
2012-09-06 12:31 bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1 Robert Dallas Gray
@ 2012-09-06 16:57 ` Glenn Morris
2012-09-08 13:29 ` Jan Djärv
1 sibling, 0 replies; 8+ messages in thread
From: Glenn Morris @ 2012-09-06 16:57 UTC (permalink / raw)
To: Robert Dallas Gray; +Cc: 12368
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
2012-09-06 12:31 bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1 Robert Dallas Gray
2012-09-06 16:57 ` Glenn Morris
@ 2012-09-08 13:29 ` Jan Djärv
2012-09-12 18:22 ` Glenn Morris
1 sibling, 1 reply; 8+ messages in thread
From: Jan Djärv @ 2012-09-08 13:29 UTC (permalink / raw)
To: Robert Dallas Gray; +Cc: 12368
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
2012-09-08 13:29 ` Jan Djärv
@ 2012-09-12 18:22 ` Glenn Morris
2012-09-12 20:30 ` Jan Djärv
0 siblings, 1 reply; 8+ messages in thread
From: Glenn Morris @ 2012-09-12 18:22 UTC (permalink / raw)
To: Jan Djärv; +Cc: Robert Dallas Gray, 12368
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).
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
2012-09-12 18:22 ` Glenn Morris
@ 2012-09-12 20:30 ` Jan Djärv
2012-09-12 20:41 ` Glenn Morris
0 siblings, 1 reply; 8+ messages in thread
From: Jan Djärv @ 2012-09-12 20:30 UTC (permalink / raw)
To: Glenn Morris; +Cc: Robert Dallas Gray, 12368
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
2012-09-12 20:30 ` Jan Djärv
@ 2012-09-12 20:41 ` Glenn Morris
2012-09-19 6:51 ` Jan Djärv
0 siblings, 1 reply; 8+ messages in thread
From: Glenn Morris @ 2012-09-12 20:41 UTC (permalink / raw)
To: Jan Djärv; +Cc: Robert Dallas Gray, 12368
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
2012-09-12 20:41 ` Glenn Morris
@ 2012-09-19 6:51 ` Jan Djärv
2012-09-19 21:21 ` Andy Moreton
0 siblings, 1 reply; 8+ messages in thread
From: Jan Djärv @ 2012-09-19 6:51 UTC (permalink / raw)
To: Glenn Morris; +Cc: Robert Dallas Gray, 12368-done@debbugs.gnu.org
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.
^ permalink raw reply [flat|nested] 8+ messages in thread* bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1
2012-09-19 6:51 ` Jan Djärv
@ 2012-09-19 21:21 ` Andy Moreton
0 siblings, 0 replies; 8+ messages in thread
From: Andy Moreton @ 2012-09-19 21:21 UTC (permalink / raw)
To: 12368
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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-09-19 21:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-06 12:31 bug#12368: 24.1; x-parse-geometry broken in Emacs 24.1 Robert Dallas Gray
2012-09-06 16:57 ` Glenn Morris
2012-09-08 13:29 ` Jan Djärv
2012-09-12 18:22 ` Glenn Morris
2012-09-12 20:30 ` Jan Djärv
2012-09-12 20:41 ` Glenn Morris
2012-09-19 6:51 ` Jan Djärv
2012-09-19 21:21 ` Andy Moreton
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).