[Openmcl-devel] Cocoa IDE and ccl-init
R. Matthew Emerson
rme at clozure.com
Fri Nov 30 13:36:06 PST 2007
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
So, we say,
(def-cocoa-default *use-screen-fonts* :bool t "Use bitmap screen fonts
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)
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
More information about the Openmcl-devel