"Drew Adams" <[EMAIL PROTECTED]> writes: > There is no noticeable delay even for commands bound to a few > dozen keys, but self-insert-command is bound to zillions of > them. It is essentially a special case that needs to be treated > as such, or else, as I say, the list of keys should be computed > only up to some limit. > > Some more info on this, FYI: In my build, on my machine, measuring using > this (thanks, Lennart) gives 0.701 seconds (IIUC):
So what is the problem? How often do you ask that same question? Even if it took 2-3 seconds, I don't see the importance of fixing this. > Doing the same thing for command `forward-char' gives 0.05 seconds: > > => (17713 7521 950000) (17713 7521 960000) > > That's an order of magnitude difference (factor of 14). And 0.7 seconds > renders this essentially non-interactive, especially when combined with the > possible overhead of other processing (e.g. calling describe-function from > another command). Huh? Who would do that (more than once)? If you have code which (senselessly) calls describe-function for self-insert-command, maybe you could do the clever part... > Besides, all of that processing time is simply wasted, My computer spends more time in the idle loop than anything else, no matter how fast I throw commands at it. I think I can spare 0.7 seconds. > since the calculated > key bindings are just thrown away, replaced by the "many ordinary text > characters" help. The code should be smarter than that. I don't see why! And anything smarter could mean that it would have to know something in advance - and how can it do that? You cannot just modify describe-function to always say "many ordinary chars"; for self-insert-command, as the user may actually rebind all chars to something else! IMO, there is no problem here. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
