[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loading Double-clicked files

> To: info-mcl@cambridge.apple.com
> Path: 
> From: buehler@merrimack.edu
> Newsgroups: comp.lang.lisp.mcl
> Subject: Loading Double-clicked files
> Date: 7 Dec 92 22:20:47 GMT
> Organization: Merrimack College, No. Andover, MA, USA
> Lines: 5
> With older versions of MCL,from the finder, if you double-clicked
> on an MCL file, LISP was started and the file was loaded.
> With MCL 2.0, LISP is started, but the file is presented in a FRED
> window instead of being loaded.  Is there a way of restoring the
> old behavior?

I got burnt by this also. If you compile the .lisp file,
then you can double-click on its .fasl and it will be loaded instead
of edited. I very much wanted to have an editable text file
that I double-click on in the listener and have it be loaded.
There may be a way to set the file type in Res-edit to get a
.lisp file to load, but I think when you Fred edit the file,
it goes back to its original type which causes it not to load when
double-clicked on in the finder. 

My kludge work-around for the
new MCL is to have a file called
load-my-init-file which just contains:
(load "my-app-init-file.lisp")
I compile the "load-my-app-init-file.lisp" so that I
can double click on load-my-init-file.fasl and
have it load "my-app-init-file.lisp".
This way I can edit my init file [something I do almost every
session], save it and not have to recompile it.

I don't want to compile my-app-init-file for 2 reasons:
One is that it is very small so the difference in 
loading the .lisp and .fasl is insignificant, and I edited
all the time so I don't want to have to remember to compile it,
or waste the time to do so.

Another is that I deliver my-app as a standalone app.
I let our users edit "my-app-init-file" with their own
customizations. But since the compiler isn't in the
standalone, they couldn't compile it if they wanted to.

The users of my-app aren't necessarily sophisticated
Mac users so making my-app easy to use is paramount.
So I don't want to have to tell them how to use RESEDIT.

I'm also not thrilled that I have to have this extra file,
"load-my-ini-file". What's not apparent from above is,
sometimes there is more than one user of my-app on a given machine.
So each user may want their own init file. And I don't know the
names of the potential user's before hand so I can't create
"load-my-app-init-sam.fasl", "load-my-app-init-jack.fasl"
when I hand out the standalone. Since the users don't have the compiler
they couldn't create them even if they knew how.

I have ways around most of these problems, but the new 
"edit double-clicked .lisp files" vs load them makes my job
a lot harder and probably requires more work for the user too.
I will probably have to have the user "log in" instead
of just double-click on their own init file which would load
my-app AS WELL AS log in for them.