[Openmcl-devel] Cocoa IDE and ccl-init
gz at clozure.com
Sun Dec 2 12:00:04 EST 2007
At 12/2/2007 10:28 AM, Gary Byers wrote:
>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.
True. But it does maintain the illusion *package* controls what the
current package is. When I set *package* to a new value, that's the
value that is subsequently used (if only to signal an error if the
value is unsuitable).
>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.)
I agree that whatever means we provide to allow users to
programmatically set the listener's output font name preference will
have to be careful to address any technical difficulties involved in
programmatically setting the listener's output font name
preference. If I seemed to be saying otherwise, I didn't mean to.
I also don't disagree that it's not the end of the world to have to
learn that *listener-output-font-name* has certain restrictions on
its possible use as a way to view and/or change the listener output
font name. But (listener-output-font-name), or perhaps even
(user-preference "Listener Output Font Name"), makes the restrictions
more intuitive, makes it easier to have fewer such restrictions if we
choose to, and doesn't seem to have much a down side. So given a
choice between the two, I still think it'd be a better design to have
an API that uses functions rather than variables.
>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
>>>>>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.
>>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
>>>Openmcl-devel mailing list
>>>Openmcl-devel at clozure.com
>>Openmcl-devel mailing list
>>Openmcl-devel at clozure.com
More information about the Openmcl-devel