> If the messages are just printed in the message buffer it shouldn't
> impact too much the startup time I think.
To do the kind of analysis you are talking about, one would have to
hook into really basic subroutines like `setq`. I don't have any
numbers to back this up, but that sounds like it would be a massive
slowdown for all Elisp code. Alternatively, you'd have to do a lot of
heavy static analysis because what defines a "outdated, deprecated, or
useless" setting is actually quite nebulous and complicated.
I do actually think this is an interesting idea, but it would
definitely best be implemented as either a third-party package or some
optional user library in core that either does static analysis or
allows one to load the init-file with profiling enabled like ESUP [1]
(or both).
> a number of people find even an extra 0.5s-1.0s in startup to be
> significant
I am one of those people, and actually I find even an extra 50ms of
startup time to be unacceptable unless there's a good reason for it.
My ~5,000 line configuration [2] which pulls in ~130 packages takes
only ~250ms to load, according to a startup profiler -- meaning 0.6s
to go from nothing to a full graphical frame.
Why bother with the Emacs server when you can just make Emacs start up
as fast as Vim? ;)
-------
I am a server user. But I dont accept anything that impacts badly performance. Thats why I would prefer a real lisp to gcc compiler in emacs instead of a jit compiler for example. I am so tired to heard vim users talking about how fast it is....
Never the less my initial intention was oriented only to the first startup without a config for newies. So there is nothing about the possible implementations on the table yet. First we need to get some information from the user. Because sometimes it looks like developers forget that isers are the key.
Does anyone care about the questions I added? Or at least could anyone tell me if there is a good online platform I could use for the feedback?
----