Re: loading the lisp/term/*.el files

[Károly Lőrentey]

[[Cc-ed on emacs-devel]]

I understand this is really not the right time for discussing new
feature development, but just a quickie:

Would anyone object if, for the multi-tty feature branch, we would
move towards autoloading/executing stuff in lisp/term/*.el in the
standard way instead of loading these files explicitly over and over
again?



Details below.

* * *

Dan Nicolaescu <address@hidden> writes:
> It seems that for multi-tty loading the lisp/term/*.el terminal files
> every time a terminal frame is create is wasteful. 
> For example term/xterm.el defines some functions that are getting
> redefined every time term/xterm.el is reloaded. 
>
> Maybe the terminal initialization can be changed so that each
> term/XXX.el file defines a function called XXX-initialize-terminal
> that is autoloaded (the autoload will take care of loading the file
> just once). 

This is exactly what I was thinking about lately. :-) I did not go
ahead and implement the idea, though, because the code is littered
with indications that lisp/term/*.el is sometimes heavily tweaked by
users.

The autoloads would also take up some extra space in memory that would
be mostly unused.

That said, two dozen short new entries in loaddefs.el seem
insignificant to me, and for me it seems easier to define
foobar-initialize-terminal in my ~/.emacs than to create an obscure
file somewhere.  Also, the rewrite would trigger a new audit to see if
these files change global state, which would be useful.

> When initializing the terminal we can do something like:
> (when (fboundp ' XXX-initialize-terminal)
>    (XXX-initialize-terminal))

A (slightly safer) alternative to this would be to look up the
function to call in an alist, similar to frame-creation-function-alist
in multi-tty.

> All the code that is not at the top level in all the term/XXX.el
> should move to the corresponding XXX-initialize-terminal functions.
>
> Obviously this is not urgent, so it can wait to be done after
> multi-tty is merged... 

Well, seeing how much grief these files have caused so far, it might
be easier to just sit down and do the cleanup now.

What do you think?  Any objections?

-- 
Károly

pgpQhqQQZmldS.pgp
Description: PGP signature