In message <87smzjh72g.fsf(a)tleepslib.sk.tsukuba.ac.jp> (on 7 October 2002 01:21:11
+0900), stephen(a)xemacs.org (Stephen J. Turnbull) wrote:
I apologize if this is overly bad-tempered, but I really, really hate
dealing with Lisp, among other things, and also really don't like GUIs in
general - X Windows is about the limit that I can deal with. Due to brain
damage, I've got enough of a difference between verbal and nonverbal IQs for
it to be a disability in and of itself, and thus have great difficulty with
trying to figure out how a nonverbal language like Lisp is working - just as
much as I do trying to figure out what people mean their GUIs to be
doing. (Given this, it is unsurprising that my favored programming language
is Perl... the presence of cperl-mode (which should really have some
increased backward-compatibility enhancements...) is one thing causing me to
favor emacs/xemacs. I'm also now going with VM as a mailer due to, among
other things, the restrictive anti-open-source policies of the PINE
developers (no distribution of modified versions), incidentally.)
>>>>> "Ed" == Ed Allen Smith
for info don't seem to work, BTW. It's also not helpful to be
asked to do a "M-x emacs-version" when the results from that show
up in the minibuffer, which results in it not being
cuttable-and-pasteable (which might be necessary if this
bug-mailing function doesn't work).
If things are that hosed, there are other reasons why you're going to
need to be sophisticated enough to use M-x view-lossage or C-x b "
*Message-Log*" to get the output. I think our play here is to make
the report function as robust as possible.
This is preferable, yes.
B. Errors in a custom.el file show up as being in the init.el file
(specifically, if there's a parentheses imbalance in the
custom.el file, an "End of file" error shows up for the init.el
file... not the custom.el file).
Because of the way XEmacs handles these files, I suspect that you
probably have imbalanced parens in _both_ files.
No. It was custom.el. Changes in init.el didn't do anything; changes in
custom.el, namely locating a forgotten parenthesis, did.
I'll check when I get back to my devel workspace, though.
N.B. custom.el is designed to be written only by code that prints
sexps, there is no user-editable code in there.
If I wanted to deal with software without user-editable parts, I wouldn't
use open-source software...
If you are getting imbalanced parens in custom.el, all I can say is
"whatever you're doing, it's unsupported by XEmacs.org".
I'm afraid that you'll need to get the customization features a _lot_ better
(including clearer, etcetera) before it won't be necessary to edit
custom.el, especially when porting from an earlier version of XEmacs, when
trying to figure out the corresponding modifications to a site-init.el file
(so that I don't have to create seperate custom.el files for root et al
accounts on all the machines...), etcetera.
C. XEmacs gives errors when there isn't an init.el file, which
particularly maddening when the cause of removal of the init.el
file is the previous problem.
Given that I'm currently in the middle of editing some modules for BioPerl,
doing email via VM, etcetera, I'm afraid that I can't tinker with things at
the moment - I will try to get back to you with this info.
D. auto-autoload.el should _not_ be doing "error" if a
It's not doing error (which means to stop loading autoloads and throw
Then why is the function called "error" (holding head...)?
it's giving a warning about a very-hard-to-debug
situation. Live with it or use display-warning-minimum-level; that
information is needed to help other users.
You're saying that we'll never need any of the information that
display-warning-minimum-level will cut off?
already included; it should simply return.
Wrong. If auto-autoloads detects that it has been previously loaded,
that means one of three things: a bad build,
Doesn't seem to be the case.
multiple copies of packages on your load-path,
Not the case, unless it's looking in the old xemacs-20.4 directory.
or a seriously mutilated load-path.
It's loading from one directory and its subdirectories, the major ones being
lisp (normal installed code), xemacs-packages (packages), and site-packages
(one subdirectory, lisp, with site-init.el in it).
Either way, we want XEmacs to yell about it.
Ed> (As it is, I'm writing a Perl script to correct all the
Ed> auto-autoload.el files, since there doesn't seem to be a way
Ed> to automatically reconstruct them properly.
Don't do this. It is a known design bug in the package system that
there is no easy way to build the packages correctly without checking
out the whole source hierarchy. However, it is not going to be easy
to fix in a backward compatible way.
I see. Unfortunate.
In the meantime I strongly urge
you to find all the copies of the package hierarchy you have
installed, delete them, download the sumo tarball (tarballs if you
Not doable - one reason that we've been forced to upgrade to Xemacs 21.* is
that 20.*'s use-every-package system resulted in entirely too much
memory/swap-space consumption. (BTW, speaking of this, if one is not doing a
MULE xemacs, why pray tell is it considered necessary to have iso-8859-1
capabilities, as opposed to us-ascii? I note that 'x-iso8859-1.el' and
'iso8859-1.el' are, for some reason, not in the 'mule' directory - why
one is present at all in a non-MULE xemacs is also mystifying.) Admittedly,
IRIX has problems with memory and swap space... incidentally, if people ever
start looking at doing Xemacs with threading, you will need to use the
standard IRIX malloc, not any other malloc. sbrk is _not_ thread-safe on
IRIX! IRIX's malloc has internal thread coding so that it _is_ thread-safe
to use, but only if it's the only thing doing memory allocations. Currently,
xemacs' malloc does seem to be working, which I do find impressive, BTW -
good job with it.
and reinstall packages from scratch. Unless you have a
really slow (worse than ISDN) link,
Network speed is not the problem by any means.
this will be faster than doing it by hand, and much more likely to
I didn't do the editing by hand... after some experimentation, I concluded
that there wasn't any way to easily persuade them to simply skip all the
initiation code if it'd already been done (lisp badly needs a _built-in_ return
command...), so I wrote a script that went through and deleted the
error-exit line. This has not caused any easily-noticeable problems; it's
possible that things are being slowed by loading more than once, however,
especially when going into the customization code.
If you're meaning the package-dependency coding, I would agree that there
are problems - many packages seem to be down as depending on gnus when they
actually simply are _helpful_ to be used _with_ gnus, but there are other
packages they're also usable with, for instance, although this is more an
author's problem than with the code.
Since you only show the md5 shadow, I conclude there is something
wrong with either your build
What? Only possibility is because configure needs to allow input of more
detailed path information, instead of making one do it at the make and make
install stage - unless configure already can do this, and it isn't
documented? (sh configure --help gives, interestingly enough, the error "|:
No such file or directory", which I will confess I find odd; other configure
arguments don't cause this, and it isn't because IRIX uses the Korn shell
instead of the Bourne shell by default - bsh configure --help gives the same
or your init files (user or system);
(setq auto-mode-alist (cons '("\\.pm$" . cperl-mode) auto-mode-alist)) ;
(setq auto-mode-alist (cons '("\\.not$" . text-mode) auto-mode-alist)) ;
(setq auto-mode-alist (cons '("/tmp/[^.]*/\\.ed[^/]*$" . text-mode)
auto-mode-alist)) ; MediaMail
(setq auto-mode-alist (cons '("\\.tmpl$" . c-mode) auto-mode-alist)) ; Imake
(setq auto-mode-alist (cons
'("config/\\(cf/\\)?[^/]+\\.\\(cf\\|def\\|rules\\)$" . c-mode)
auto-mode-alist)) ;; Imake cf, def, and rules files
(setq auto-mode-alist (cons '("\\.login$" . shell-script-mode)
auto-mode-alist)) ; Login scripts
(setq auto-mode-alist (cons '("L[0-9]+\\-[0-9]+TMP$" . text-mode)
auto-mode-alist)); Lynx temp editing files
(set-face-foreground 'font-lock-comment-face "Red")
(add-hook 'perl-mode-hook 'turn-on-font-lock)
(add-hook 'cperl-mode-hook 'turn-on-font-lock)
(setq-default cperl-label-offset 0) ; No label offset
(setq-default font-lock-maximum-decoration t)
(setq text-mode-hook 'turn-on-auto-fill)
(add-hook 'text-mode-hook 'turn-on-filladapt-mode)
(setq html-mode-hook 'turn-off-filladapt-mode)
(setq html-mode-hook '(auto-fill-mode 0))
(setq hm--html-mode-hook 'turn-off-filladapt-mode)
(setq hm--html-mode-hook '(auto-fill-mode 0))
(setq-default line-number-mode t)
(setq ediff-diff-options "-bdB")
(setq-default coding-system-for-write 'raw-text)
'(paren-mode (quote sexp) nil (paren))
'(default ((t (:background "white"))) t)
'(yellow ((t (:foreground "yellow" :background "gray80"))) t)
'(cperl-nonoverridable-face ((((class color) (background light)) nil)))
Given that it was showing up with _all_ packages, I would not think the "load"
or "require" statements in the above would be enough to cause
problems. Given that it was happening no matter _what_ was done to the
init.el files, and for all users, I don't think it can be user init files
(unless it's a problem with installing the updated versions - .emacs does
_not_ seem to get created properly, for instance, if there was an old
version that is now supposed to be referring to .xemacs/init.el).
otherwise you would not be getting duplicate loads of the packages.
Umm... methinks you are making assumptions of perfect coordination of
packages dependent on each other wanting loading (possibly when they
autoload to supply a function, if that's how this works?) that may not be
allowing for unanticipated but non-erroneous situations.
My nostalgia for Icon makes me forget about any of the bad things.
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
For those of us who have brain damage restricting our non-verbal abilities,
a verbally-oriented programming language like Perl is a "god"send...
Allen Smith http://cesario.rutgers.edu/easmith/
September 11, 2001 A Day That Shall Live In Infamy II
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin