[Openmcl-devel] Cocoa IDE and ccl-init

[Gary Byers]

I have the illusion that I can do

(setq *package* (random 100))

in my init file, but the system doesn't usually let me maintain that
illusion for very long.

If I use some more constrained way of assigning to *PACKAGE* -
like IN-PACKAGE - and if I assume that other code does so as well -
then I can be reasonably sure that the value of *PACKAGE* is in
fact a package.

I think that I believe that people can similarly learn (perhaps
after being told) that doing (SETQ GUI::*LISTENER-OUTPUT-FONT-NAME* ...)
directly is a bad idea, and that's mostly orthogonal to the question
of whether that state should be accessed via a special variable.

Whether the state's accessed via a special (static) variable or not,
the advertised alternative to SETQ for these things has to be pretty
careful, not only to interact correctly with the preferences system
but to ensure that the change happens in a thread-safe way.  (It might
create problems if some other thread changed a piece of state while
the event thread was in between accesses to that state, and this is
true whether that state's accessed via some encapsulating function or
just a static variable.)




On Sun, 2 Dec 2007, Gail Zacharias wrote:

> At 11/30/2007 04:36 PM, R. Matthew Emerson wrote:
>
>> 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.
>
> Regardless of what else we do, I think this is a good idea.  There is
> no good reason to set up an illusion that we can't fully maintain, or
> have to jump through all sorts of hoops to try to
> maintain.  (use-screen-fonts) is no harder to type than
> *use-screen-fonts*, and doesn't require a section in the doc
> explaining why you can't bind it.  Personally, I might even prefer
> something like (user-preference "Use Screen Fonts")...
>
>
>> Or, we could stop using NSUserDefaults to store preferences, instead
>> saving them in a lisp file in ~/Library/Application Support/Clozure CL
>> or something.
>>
>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>