[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Loading a file from the finder
- To: firstname.lastname@example.org (Bill St. Clair)
- Subject: Re: Loading a file from the finder
- From: cfry@MIT.EDU (Christopher Fry)
- Date: Tue, 25 Feb 92 16:34:25
- Cc: email@example.com
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 [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
- 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]