Chris Waters writes: > I *strongly* oppose eliminating it, and I'm not real big on the idea > of making the default be "off". Installing new packages takes a > while, I don't mind a few extra moments there. I *do* mind run-time > delays, even if they're small,
There is always a delay; this is unavoidable. The question is how big the delay is. How often have you timed the startup times for these packages? > and only once per session (and they're not if you unload features to > save RAM). If there's a bug in the install, it should be reported > and fixed, but I have yet to see one. See bug reports 37375, 37355 for a couple of examples. > That said, I'm perfectly happy to see it be optional, as long as it > doesn't result in more install-time questions. But the *default* > should be whatever is best for the novice running stable. Which is > "on", since a novice may not be able to figure out how to byte-compile > the package himself. And stable *better* not have problems in the > install, so problems in the install aren't sufficient justification > for a default of "off". The current scheme can generate hundreds of lines of noise from which just one or two lines need to be extracted to determine even what package(s) the bug is in. See the discussion in bug report 37355 for an example. Run-time compilation of elisp would slow things down slightly. In many cases if you didn't time it, you wouldn't even notice. I know what I think is better for the novice! ttfn/rjk
