Re: (describe-function 'self-insert-command) takes too long

[Kim F. Storm]

"Drew Adams" <address@hidden> 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 <address@hidden> http://www.cua.dk