"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? > > What question?
(describe-function 'self-insert-command) > Huh? Who would do that (more than once)? > > Who would do what more than once? Ditto. > > If you have code which (senselessly) calls describe-function for > self-insert-command, maybe you could do the clever part... > > I have code that provides a browser of keys and their bindings. As a side > feature, you can get help about a binding on the fly, during completion > (e.g. before using it). You C-click (or C-RET) a completion candidate to see > its help. For keys bound to self-insert-command, the help appears only after > a second or two delay. For all other keys, the help display is > instantaneous. So why can't you special-case self-insert-command yourself? YOU are the only one who knows what to expect here... > describe-function should be a quick command - quick enough to click a key > bound to it and see the help result immediately. A one- or two-second delay > is not very interactive. Command self-insert-command is the only exception, > which causes describe-function to be slow. I haven't seen any evidence that it isn't quick "enough" for all practical purposes. And you can easily work around the slowness for self-insert-command. > Looking up bindings is only a tiny part of what describe-function does. describe-function doesn't look up those bindings -- where-is-internal does that. And where-is-internal is a generic command which should return all bindings. [it could have an optional LIMIT arg though]. > Irrelevant. When you click a button (or whatever), you don't expect its > dialog box (or whatever) to be displayed after a delay of a couple of > seconds; you expect it to appear immediately. When I ask a question, like C-h k a, I don't expect it to complete immediately if the answer is complex. > > 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 I don't see why not (nor why you are so sensitive about this, > apparently). Why compute (look up) 5000 bindings and then throw them away? > Why not compute bindings only up to a max of, say, 100 (or 200 or 400, but > certainly not 5000)? I'm not sensitive to this -- I just don't see a need to fix something which isn't broken (IMO). > And anything smarter could mean that it would have to know something > in advance - and how can it do that? > > What does it have to know? It can just stop calculating when it has already > found 100 bindings. Put the length filter inside the loop, instead of > outside it - filter promotion; that's all. Tell me, if I'm misunderstanding > (and no need to shout). AFAICT, this shouldn't be a big deal. I'm not against doing that if it is the right fix. However, the where_is_internal code is a bit tricky, so this is not the right time to change it. -- 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
