[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan Djärv
Subject: bug#10103: 24.0.91; Emacs/nextstep ignores frame geometry from org.gnu.Emacs.plist
Date: Sat, 10 Dec 2011 15:01:59 +0100


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

> Hi,
> Jan Djärv <address@hidden> 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 

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]