Re: Loading a file from the finder

[cfry@MIT.EDU (Christopher Fry)]

Wow. Lots of responses. Thanks, group.

Both Straz and bill suggested ways for the user to modify
MCL to load-instead-of-edit" a file  that is double-clicked on in the 
finder. While these will work after the lisp is already up,
I need it to work when MCL isn't even runniung yet.

Here's the basic paradyme.
I'm presenting the user with a file to double-click on in the finder and 
they need not be aware that that the program that comes up is actually 
MCL with a bunch of stuf added to it.

A good sugestion was compiling the file into a fasl. [ Mark Nahabedian 
and perhaps others] also will work, but I was hoping to avoid my users 
from having to know about compiling files.

Steve Mitchell suggested that the stand-alone appications that we build 
contain some more user-friendly way of keeping user customizations, and 
in fact they do. But we have a number of users who run in non-standalone 
mode. Also, we have multiple-users on one machine. Its nice to have a 
folder of customization files named things like:
fry-customizers.lisp  that I can just double-click on from the finder. 
This avoids me having to type in my user name to get my customizers.

Maybe what would be good is to have a per-file way of declaring that a 
text file is to be loaded instead of edited when you double-click on it.
Having a different Mac file type would screw up things like 
choose-file-dialog and perhaps other things.

Perhaps just a "magic number" at the beginning of the file contents, say

:load-me-from-finder
or even 
;load me from finder  [though this makes it harder for a user to
write the code that determines the kind of file.] If MCL provides 
load-from-finder-p  externally available, then this objection goes away.

When the user double-clicks on a file from the finder, [including when 
MCL is not yet loaded] if the first string is the magic number, load it.
- Since the magic number [ a keyword symbol] is harmless when loaded, we 
don't even have to avoid evaling it. 
- Since switching between finder and lisp takes many times longer than 
parsing the magic number, speed shouldn't be an issue.  
- Since we don't change the Mac file type, the existing  open will work 
as is.  
- Since its just text in the file, the user doesn't have to know about 
res-edit to change the file type, they can do it all within Fred.

- You've still got to document that the facility exists, but when you 
see a file that has a well-spelled magic number in it, it gives you a 
strong clue as to what it means.

- Since its on a per-file basis, you don't have to declare all text 
files to be loadable in one fell swoop, but get to customize on a 
per-file basis. [Though perhaps being able to switch to loading as the 
default behavior wouldbe good for some users. I'd be happy with having 
to explicitly edit each file that was to be loaded in this way.]

We could have the "If cmd/shift/option key down, load" syntax. That 
doesn't interfere with the magic number scheme. It should just override 
it. But I hate to have to document and re-discover all these cmd-click
invocations rampant on the mac.

The Lisp Machine had file attributes at the top of text files. This 
would be a perfect application for that mechanism.
I vaguely remember GZ implementing something like that at Coral.
Gone or am I mis-remembering? 

[Bill, I agree, no rush on this for 2.0]