[Openmcl-devel] Cocoa IDE and ccl-init

[Gary Byers]

On Fri, 30 Nov 2007, Andrew Shalit wrote:

> I
>
> 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>).
>> 
>> It's probably sanest to load ~/ccl-init.lisp (nee ~/openmcl-init.lisp)
>> in the IDE's initial listener; that's similar to what happens in the
>> TTY world, so if your init file wants to print messages or request
>> input (or enter a break loop ...) there'd be a way of supporting that.
>> 
>> 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.
>
>

Right now, a bunch of lisp variables are magically set whenever the
preferences are read or updated.

That's sort of convenient: the application reads the preferences,
and *LISTENER-OUTPUT-FONT-NAME*  is set appropriately (along with
a dozen or so other things.)

If you then say (in your IDE customization file)

(setq *listener-output-font-name" "Courier")

newly created listeners will use Courier for output, but the preferences
system won't see that change.  (That wouldn't be the end of the world,
but it would/could introduce inconsistency and could lead to confusion.)

If we invented something like:

(set-ide-preference *listener-output-font-name* "Courier")

where SET-IDE-PREFERENCE does whatever needs to be done to synch
with the preferences system ... OK.

(There's a separate issue of whether the convenience of dealing
with special variables outweighs the lack of encapsulation that
they provide; that's true of most of the special variables in CL ...)