[Openmcl-devel] Cocoa IDE and ccl-init

Raffael Cavallaro raffaelcavallaro at mac.com
Sun Dec 2 09:56:52 PST 2007

On Dec 2, 2007, at 12:00 PM, Gail Zacharias wrote:

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

I'm a little leery of entering this discussion, but fools rush in  
where angels fear to tread, so that at least qualifies me ;^)

It may be worth noting in this context that it is already possible to  
use the command line to change user preferences. From a terminal:

defaults write "com.clozure.Clozure CL" cclDirectory "/Users/raffaelc/ 

will actually change the user preference stored in ~/Preferences/ 
com.clozure.Clozure CL.plist and it is visible in Clozure CL.app at  
least after restarting the IDE - I would say that the need for a  
restart is a cacheing bug in the IDE, but that's possibly a matter of  
preference (pun intended).

In any event, providing an API like:

(defaults-write 'ccl-directory "/Users/raffaelc/Developer/lisp/ccl/")

(defualts-write 'hyperspec-lookup-enabled nil)

etc., and loading the (possibly) modified preference file *after*  
loading the init file would make it possible to do both preferences  
dialog stuff and lisp stuff from an init file.

In addition, as long as the current convention for mapping from  
camelCase to lisp-speak is maintained, the preference values to be  
written would be self documenting in the plist file.

just my $.02



Raffael Cavallaro, Ph.D.
raffaelcavallaro at mac.com

More information about the Openmcl-devel mailing list