Re: shell unmaintainable [Re: comint + shell still hosed]
Please keep the discussion on the list.
"Ilya N. Golubev" <gin(a)mo.msk.ru> wrote:
> Are you sure you have the shell.el as of 2006-06-01?
It was an error in change merge. Because of continuous committing
buggy versions in upstream, had to maintain a distinct local one.
With `shell.el' as of 2006-06-01 fully duplicated, finding no more
bugs. As for being able to run `comint', `shell', considering it
closed.
I am happy to have had your help in identifying bugs in the sync, but I
don't understand why you think you have to maintain a distinct local
copy. Can't you just stick with the officially released packages? If
you are installing test packages, then you've agreed to be a tester.
And you've been a good one, so I hope you continue, but you shouldn't
feel like you are required to be a tester.
One reason to still maintain another `shell.el' version is that
is
still has a maintainability bug. It does not `(require 'font-lock)'
in run time, but does so in `eval-when-compile'. Already wrote that
`font-lock' has a (IMO, mis-) feature of enabling itself on mere load,
so there may be strong reasons not to load it. That perhaps makes no
difference when compiling `shell.el' in batch mode, but user may need
his own version of the file, and compile it by executing
`byte-compile-file' interactively. In this case the undesired changes
in his environment will occur.
What is the purpose of such a `require' in `eval-when-compile'? If it
is only to shut warnings about use of `font-lock-mode-hook', this
variable is autoloaded, but in `auto-autoloads.el'. In this case
should `(require 'lisp-autoloads)'.
Changing `font-lock' not to enable itself on load (in all xemacs
branches) perhaps would be even better.
Are you worried about this?
------------------------------------------------------------------------
;; Install ourselves:
(add-hook 'find-file-hooks 'font-lock-set-defaults t)
------------------------------------------------------------------------
I don't see anything else in font-lock.el that makes an obtrusive change
to the user's environment.
As for the byte compiling issue, (require 'auto-autoloads) is not the
right thing to do, because there are lots of auto-autoloads.el files,
one per package in fact. It is true that this is just to quiet a byte
compiler warning. That may be considered a small thing by some, but I
try to get rid of such warnings whenever I touch a package. I have this
dream that, eons from now, some XEmacs developer may be able to notice
that there were 2 warnings when compiling the packages and go fix the
problem. Right now, we get so many warnings that they are nearly
worthless.
We could drop the require of font-lock and get the warning back. I'm
not terribly concerned about this, though, because (1) we distribute the
packages in precompiled form, which is good enough for the vast majority
of users; and (2) anybody who needs to compile their own due to
maintaining local variations should be sophisticated enough to deal with
a change in find-file-hooks.
--
Jerry James, Assistant Professor Jerry.James(a)usu.edu
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University