brad> Ian, I am finally working on a major update to the id-utils
brad> package. With regard to this bug report, I see no advantage to
brad> adding the complexity of byte compiling this file. id-utils is
brad> not primarily an emacs related package and I believe it should not
brad> depend or build-depend on emacs (it did depend on emacs at one
brad> time). The elisp functions in id-utils.el are very short and not
brad> at all constrained by performance at load or run time.
brad> It seems to me that adding support to byte compile this trivial
brad> file for all flavors of emacs only complicates the package and
brad> slightly increases the installed size of the package.
brad> But I may be missing something. Do you agree or do you have a
brad> reason to request this change that I have not considered?
I think it was a kind of "long story". I started with #367599 where
it's actually important - _that_ lisp file is huge, it is relatively
slow to load, and OTOH there's no way to get its embedded docstrings
without loading it _in toto_ because there are no autoloads. So I stand
behind #367599, but then I got carried away and filed bugs about all
uncompiled .el files I could find. I agree, id-utils.el can be loaded
from one's .emacs without any problem.
--
She had a passion for anyone who could do anything really well.
... "Not for an engineer, not for a technician!"
Mikhail Bulgakov, The Master & Margarita
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
