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

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

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.