9:12 p.m.
Jerry James <Jerry.James(a)usu.edu> writes:
Can't you just stick with the officially released packages?
No. Reasons are too complex.
I don't see anything else in font-lock.el that makes an obtrusive
change
to the user's environment.
When something in that package did, did not bother to document it
fully, just remembered to avoid loading it. Even
(add-hook 'find-file-hooks 'font-lock-set-defaults t)
may be quite harmful, depending on how much `font-lock-set-defaults'
hogs the cpu. If it hogs much, being <sophisticated> helps little.
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.
Right. Is not core `lisp' directory first in `load-path' when
`-no-autoloads -vanilla' are specified, when compiling packages in
batch mode? If can rely on that, still can do so. Will load right
`auto-autoloads.el' in batch mode and have it already loaded in
regular interactive one.
(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.
Disagree. He may be even sophisticated, but he has time only for his
own modifications, not for meddling with some nearly unpredictable
effects like these. Leaving misfeatures like this is a recipe to have
actual work never done.
6:11 p.m.
New subject: shell unmaintainable
"Ilya N. Golubev" <gin(a)mo.msk.ru> wrote:
Jerry James <Jerry.James(a)usu.edu> writes:
> Can't you just stick with the officially released packages?
No. Reasons are too complex.
Okay.
> I don't see anything else in font-lock.el that makes an
obtrusive change
> to the user's environment.
When something in that package did, did not bother to document it
fully, just remembered to avoid loading it. Even
(add-hook 'find-file-hooks 'font-lock-set-defaults t)
may be quite harmful, depending on how much `font-lock-set-defaults'
hogs the cpu. If it hogs much, being <sophisticated> helps little.
Sure. I just wondered if you knew of anything else that font-lock does
to your environment. It appears to me that that is the sole effect it
has, other than defining symbols of various kinds, of course. So if we
fix the hook, I think you will be happy.
> 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.
Right. Is not core `lisp' directory first in `load-path' when
`-no-autoloads -vanilla' are specified, when compiling packages in
batch mode? If can rely on that, still can do so. Will load right
`auto-autoloads.el' in batch mode and have it already loaded in
regular interactive one.
Okay, but you are already making local modifications. So I suggest a
compromise. Why don't you change the (require 'font-lock) to (require
'auto-autoloads) in your own copy, or just delete (require 'font-lock)
altogether and live with the byte compiler warnings. In the meantime,
I'll see what we can do about the hook change when font-lock is loaded.
> (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.
Disagree. He may be even sophisticated, but he has time only for his
own modifications, not for meddling with some nearly unpredictable
effects like these. Leaving misfeatures like this is a recipe to have
actual work never done.
All you have to do is (remove-hook 'find-file-hooks
'font-lock-set-defaults) after font-lock is loaded.
--
Jerry James, Assistant Professor Jerry.James(a)usu.edu
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University
5:20 a.m.
New subject: shell unmaintainable
Taken out of order.
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
Ilya> Jerry James <Jerry.James(a)usu.edu> writes:
> (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.
Ilya> Disagree.
I have a lot of sympathy for this. I prefer that use of hooks be
reserved to the user (and packages the user explicitly `require's or
`load's). IMHO, using them to implement standard features sucks. If
this is really necessary, then I would suggest putting it in the
function itself, perhaps with a defcustom enabler.
However, using the hook to *experiment* with the feature is a
reasonable strategy.
> Can't you just stick with the officially released packages?
Ilya> No.
Then you should fork. Pick a reasonably fresh version, get it working
for you, put it in site-packages (which takes precedence over the
other hierarchies for precisely this purpose), and update when you
feel like dealing with the instability.
The CVS trunk is for development, instability is a fact of life there.
> 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.
Ilya> Right. Is not core `lisp' directory first in `load-path'
Ilya> when `-no-autoloads -vanilla' are specified, when compiling
Ilya> packages in batch mode?
You presumably mean `-no-packages'. `-no-autoloads' sets up the
paths, but then skips loading of the autoloads. `-no-packages' is not
available in 21.4.
Ilya> If can rely on that, still can do so. Will load right
Ilya> `auto-autoloads.el' in batch mode and have it already loaded
Ilya> in regular interactive one.
Sorry, that's not going to be supported. For one, it will probably
produce spurious warnings because of the way the auto-autoloads
features are provided. We do not know what users will have in their
load-path---there may be unloaded auto-autoloads in directories
cons'ed on to the front!---and there's no guarantee that the file will
be loaded when -no-packages (-vanilla is implied, because most init
files depend on packages) is in effect.
Use `xemacs -no-packages -batch -l auto-autoloads' with 21.5. Just
lose with 21.4; I don't know of a way to implement what you want in
21.4 off-hand, although it should be possible by doing surgery on
`load-path' before loading auto-autoloads.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6505
days inactive
6510
days old
2 comments
3 participants
participants (3)
-
Ilya N. Golubev -
Jerry James -
Stephen J. Turnbull