[1671] in testers
dash perl entry
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Wed Jul 31 18:59:08 1991
From: ckclark@ATHENA.MIT.EDU
Date: Wed, 31 Jul 91 18:58:55 -0400
To: vanharen@MIT.EDU
Cc: testers@ATHENA.MIT.EDU, bug-sipb@ATHENA.MIT.EDU
In-Reply-To: Chris VanHaren's message of Wed, 31 Jul 91 12:00:28 BST <9107311600.AA21565@bad-loud-music>
Reply-To: ckclark@mit.edu
>>>>> On Wed, 31 Jul 91 12:00:28 BST, Chris VanHaren <vanharen@MIT.EDU> said:
Chris> You're a victim of bad timing on this one... :-)
Chris> If you look again, you'll see that it says to add perl
Chris> instead of watchmaker... Marc pointed this out to me the
Chris> other night, and I changed it, but the change didn't show
Chris> up until last night at 9pm with the release of the AFS
Chris> volume that contains the menus...
On garfield, (running 7.3D), as of the time of this message, the menu
still refers to the watchmaker locker.
Chris> I don't even get that far. If I start up "emacs -q" on a
Chris> VAX, I get "Warning: lisp library (/usr/athena/lib/elisp)
Chris> does not exist". It should be
Chris> /usr/athena/lib/gnuemacs/lisp, no?
The directory /usr/athena/lib/elisp has been created to hold things like
discuss.el, etc. If you examine the load-path you get, you should see
that it looks first in /usr/athena/lib/elisp, then in
/usr/athena/lib/gnuemacs/lisp. If you are getting that error, then it
means that the system packs did not have that directory at the time you
ran ``emacs -q''. Try again. I'm not sure in which order the VAX emacs
binary and /usr/athena/lib/elisp directory were installed on the packs,
but they are there now, so perhaps you are also a victim of bad timing.
:-)
Chris> Anyway, I'll look into fixing up the dash menu entry for
Chris> gnus (and discuss, which will probably break too... :-)
No, discuss does not have any problems of the same kind that cause gnus
to lose in this case. I am almost tempted to consider it a bug that
running gnus *requires* that your load-path be set so that nntp.el can
be found, which is why I've forwarded this to bug-sipb. You could solve
the problem in dash by creating a .el file which appends sipb's elisp
directory to the load-path, and then having that be called with a
separate -f to emacs when you start it up. Or SIPB could modify gnus.el
so that nntp is found even if your load-path is not set. Or you could
make dash set the EMACSLOADPATH environment variable. There are a
number of solutions. I have no opionion on the matter other than to
mention that dash menus should not give the option to start up anything
which does not work. This is especially important because when dash
starts emacs to run something in it, it uses the -q flag, so no amount
of user education will solve the problem (unless that education causes
them to stop using dash. :-), because what they do in their .emacs files
does not matter.
-Calvin
