[Openmcl-devel] Cocoa IDE and ccl-init

[Gail Zacharias]

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