> 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.
Yes, but describe-function-1 then iterates over all of the keys:
;; Which non-control non-meta keys run this command?
(dolist (key keys)
(if (member (event-modifiers (aref key 0)) '(nil (shift)))
(push key non-modified-keys)))
At least there, a count could be checked. I don't claim that would
significantly help, but if the end result is to display only 10 non-modified
keys max, then there is no sense in testing and accumulating more than 10
(certainly not ~5000). And all of the `self-insert-command' keys are
non-modified, I imagine.
And where-is-internal is a generic command which should return
all bindings. [it could have an optional LIMIT arg though].
I can't speak to whether that would be desirable or feasible. You're
probably right that that is where the main waste of time occurs.
> 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.
Maybe that's a place we differ. I don't see the answer to either
`describe-key' or `describe-function' as being complex. For
`describe-function', the list of bindings is only a side feature, and there
is no attempt to give a complete list. How we get the result might be
complex (I don't know), but the result itself is not particularly complex.
> 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.
OK. Thanks for looking into this, in any case.
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
