bug#10103: 24.0.91; Emacs/nextstep ignores frame geometry from org.gnu.Emacs.plist

bug#10103: 24.0.91; Emacs/nextstep ignores frame geometry from org.gnu.Emacs.plist

[Kai Tetzlaff]

Since about 3 weeks, the nextstep port started to ignore frame geometry
parameters (i.e. Top, Left, Height, Width) from
~/Library/Preferences/org.gnu.Emacs.plist (while some other parameters
like ToolBar and Background still seem to be working).

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/Users/kai/Work/oss/build/osx/clang/64/dbg/emacs-new/nextstep/Emacs.app/Contents/Resources/etc/DEBUG.


In GNU Emacs 24.0.91.6 (x86_64-apple-darwin10.8.0, NS apple-appkit-1038.36)
 of 2011-11-21 on mack.tetzco.de
Windowing system distributor `Apple', version 10.3.1038
configured using `configure  'CC=clang' 'CFLAGS=-g -O0' 'LDFLAGS=-g' '--with-ns' '--with-gnutls''

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_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> M-x r e p o <tab> <down> r t <tab> <re
turn>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
goto-history-element: End of history; no default available

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug help-mode easymenu view 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#10103: 24.0.91; Emacs/nextstep ignores frame geometry from org.gnu.Emacs.plist

[Jan Djärv]

Hi.

22 nov 2011 kl. 07:51 skrev Kai Tetzlaff:

> Since about 3 weeks, the nextstep port started to ignore frame geometry
> parameters (i.e. Top, Left, Height, Width) from
> ~/Library/Preferences/org.gnu.Emacs.plist (while some other parameters
> like ToolBar and Background still seem to be working).
> 

That was a cleanup that removed too much.  Now restored.

Thanks,

	Jan D.

bug#10103: 24.0.91; Emacs/nextstep ignores frame geometry from org.gnu.Emacs.plist

[Kai Tetzlaff]

Hi,

Jan Djärv <jan.h.d@swipnet.se> writes:
> 22 nov 2011 kl. 07:51 skrev Kai Tetzlaff:
>> Since about 3 weeks, the nextstep port started to ignore frame geometry
>> parameters (i.e. Top, Left, Height, Width) from
>> ~/Library/Preferences/org.gnu.Emacs.plist (while some other parameters
>> like ToolBar and Background still seem to be working).
>> 
>
> That was a cleanup that removed too much.  Now restored.
Nice, thank you!

When i first started Emacs after the fix, i got an immediate crash.
After some debugging, i found that i had accidentally changed the type
of the Height property from String to Integer. While trying to
understand what is happening i found that the following patch allows to
use either Integer or String type values in the plist file:

=== modified file 'src/nsfns.m'
--- src/nsfns.m	2011-12-04 13:25:16 +0000
+++ src/nsfns.m	2011-12-05 00:07:20 +0000
@@ -2217,7 +2217,7 @@
     /* --quick was passed, so this is a no-op.  */
     return NULL;
 
-  res = [[[NSUserDefaults standardUserDefaults] objectForKey:
+  res = [[[NSUserDefaults standardUserDefaults] stringForKey:
             [NSString stringWithUTF8String: toCheck]] UTF8String];
   return !res ? NULL :
       (!strncasecmp (res, "YES", 3) ? "true" :


Would it make sense to change objectForKey to stringForKey (in this and
some other places) when trying to retrieve a string type property from a
plist file?

BR,
Kai

bug#10103: 24.0.91; Emacs/nextstep ignores frame geometry from org.gnu.Emacs.plist

[Jan Djärv]

Hello.


5 dec 2011 kl. 01:41 skrev Kai Tetzlaff:

> Hi,
> 
> Jan Djärv <jan.h.d@swipnet.se> writes:
>> 22 nov 2011 kl. 07:51 skrev Kai Tetzlaff:
>>> Since about 3 weeks, the nextstep port started to ignore frame geometry
>>> parameters (i.e. Top, Left, Height, Width) from
>>> ~/Library/Preferences/org.gnu.Emacs.plist (while some other parameters
>>> like ToolBar and Background still seem to be working).
>>> 
>> 
>> That was a cleanup that removed too much.  Now restored.
> Nice, thank you!
> 
> When i first started Emacs after the fix, i got an immediate crash.
> After some debugging, i found that i had accidentally changed the type
> of the Height property from String to Integer. While trying to
> understand what is happening i found that the following patch allows to
> use either Integer or String type values in the plist file:
> 
> === modified file 'src/nsfns.m'
> --- src/nsfns.m	2011-12-04 13:25:16 +0000
> +++ src/nsfns.m	2011-12-05 00:07:20 +0000
> @@ -2217,7 +2217,7 @@
>     /* --quick was passed, so this is a no-op.  */
>     return NULL;
> 
> -  res = [[[NSUserDefaults standardUserDefaults] objectForKey:
> +  res = [[[NSUserDefaults standardUserDefaults] stringForKey:
>             [NSString stringWithUTF8String: toCheck]] UTF8String];
>   return !res ? NULL :
>       (!strncasecmp (res, "YES", 3) ? "true" :
> 
> 
> Would it make sense to change objectForKey to stringForKey (in this and
> some other places) when trying to retrieve a string type property from a
> plist file?

It does not work that way for me.  The documentation says that stringForKey returns:

"The string associated with the specified key, or nil if the default does not exist or does not contain a string."

and indeed, I get nil if I put in an integer for height, which makes UTF8String throw an exception.  This is the same behaviour as with objectForKey.  I tested on OSX 10.7, it may be different on other versions.

It does make sense to avoid crashing on bad user input, so I fixed it in another way.

	Jan D.
 

bug#10103: 24.0.91; Emacs/nextstep ignores frame geometry from org.gnu.Emacs.plist

[Kai Tetzlaff]

Hi,

Jan Djärv <jan.h.d@swipnet.se> writes:

> Hello.
>
>
> 5 dec 2011 kl. 01:41 skrev Kai Tetzlaff:
>
>> When i first started Emacs after the fix, i got an immediate crash.
>> After some debugging, i found that i had accidentally changed the type
>> of the Height property from String to Integer. While trying to
>> understand what is happening i found that the following patch allows to
>> use either Integer or String type values in the plist file:
>> 
>> === modified file 'src/nsfns.m'
>> --- src/nsfns.m	2011-12-04 13:25:16 +0000
>> +++ src/nsfns.m	2011-12-05 00:07:20 +0000
>> @@ -2217,7 +2217,7 @@
>>     /* --quick was passed, so this is a no-op.  */
>>     return NULL;
>> 
>> -  res = [[[NSUserDefaults standardUserDefaults] objectForKey:
>> +  res = [[[NSUserDefaults standardUserDefaults] stringForKey:
>>             [NSString stringWithUTF8String: toCheck]] UTF8String];
>>   return !res ? NULL :
>>       (!strncasecmp (res, "YES", 3) ? "true" :
>> 
>> 
>> Would it make sense to change objectForKey to stringForKey (in this and
>> some other places) when trying to retrieve a string type property from a
>> plist file?
>
> It does not work that way for me.  The documentation says that stringForKey returns:
>
> "The string associated with the specified key, or nil if the default does not exist or does not contain a string."
>
> and indeed, I get nil if I put in an integer for height, which makes
> UTF8String throw an exception. This is the same behaviour as with
> objectForKey. I tested on OSX 10.7, it may be different on other
> versions.
I'm still running 10.6, which might explain the difference.

>
> It does make sense to avoid crashing on bad user input, so I fixed it in another way.
Thanks!

> 	Jan D.
>  

BR,
Kai