[Openmcl-devel] Cocoa IDE and ccl-init

[R. Matthew Emerson]

On Nov 30, 2007, at 4:00 PM, Andrew Shalit wrote:

> On Nov 30, 2007, at 1:21 PM, Gary Byers wrote:
>
>> It's a bug (sort of related to <http://trac.clozure.com/openmcl/ticket/87
>>> ).
>>
>> There -could- be some sort of well-defined interaction between what's
>> settable via the preferences pane and what should be defined in the
>> (to be named) IDE customization file, but it seems to be cleaner
>> if there was no interaction (e.g., if the preferences system handled
>> certain things and if the customization file contained things like
>> custom Hemlock commands and key bindings.)
>
> I think it would be hard to enforce this distinction.  People are used
> to putting arbitrary lisp code in their init files, and I wouldn't
> particularly want to stop them even if we could.  Why not just specify
> the order in which they happen? I'd load the preferences first, and
> then run the init file.

It's not hard to update a set of special variables when the user  
changes something from the preferences panel, but I don't see how it  
would be possible to keep things in synch in the reverse direction.

The preferences panel uses the NSUserDefaults mechanism to store the  
preferences, and we have a sort of lispy interface to it in the form  
of DEF-COCOA-DEFAULT.

So, we say,

(def-cocoa-default *use-screen-fonts* :bool t "Use bitmap screen fonts  
when available")

and this arranges for the *use-screen-fonts* special variable to be  
set to the value of the useScreenFonts user defaults key.  This way,  
we don't have to say something like this

(#/boolForKey: (#/standardUserDefaults ns:ns-user-defaults)  
#@"useScreenFonts")

when we want to know whether we should use bitmap screen fonts or not.

The defaults system sends out a notification whenever the defaults  
change, so it's possible for us to keep the special variables up-to- 
date when the preferences are changed from the preferences panel.

If the user says in his init file

(setq *use-screen-fonts* nil)

the NSUserDefaults-based preferences aren't going to get updated, and  
the user's setting will in fact be clobbered the next time any  
preference is updated.

We could stop trying to expose NSUserDefaults-style preferences as  
lisp special variables---this wouldn't give anyone the idea that they  
could be profitably altered.

Or, we could stop using NSUserDefaults to store preferences, instead  
saving them in a lisp file in ~/Library/Application Support/Clozure CL  
or something.