bug#45379: 28.0.50; Degraded Performance of describe-buffer-bindings

[Stefan Kangas <stefan@marxist.se>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 07 Sep 2021 21:53:16 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: stephen.berman@gmx.net, handa@gnu.org, juri@linkov.net, styang@fastmail.com,
>>  monnier@iro.umontreal.ca, 45379@debbugs.gnu.org
>>
>> Ping!  Stefan, can we please resolve this issue?  I think we cannot
>> release Emacs 28 without fixing this regression.
>
> Since we are close to cutting the emacs-28 release branch, and this
> bug didn't see any loving care for a long time, I went ahead and fixed
> this performance degradation myself, based on patches by Stefan Kangas
> and their discussions in this bug report.

Thanks, I appreciate the help.

[I had intended to get to it this weekend based on your recent ping; for
 me this stuff (as opposed to ELisp shenanigans) requires a decent chunk
 of time to sit down and properly focus.]

> The feature whereby we check whether shadowing of consecutive keys is
> by the same command, which AFAIU is what caused the regression, is now
> optional, by default off.  There's a new variable,
> 'describe-bindings-check-shadowing-in-ranges', which can be used to
> turn it on, and an optional value of that variable,
> 'ignore-self-insert', which provides some partial testing of shadowing
> in these cases by trading accuracy for performance.

OK.  The bug doesn't directly affect me, but now people who are affected
can enable the bug fix.

> And I have a question about this whole "shadowing detection" feature.
> If I repeat the recipe of bug#9293, which started all this, i.e.
>
>   emacs -Q
>   C-x C-f some-tarball-file.tar.gz RET
>   M-x view-mode RET
>   C-h m
>
> then the *Help* buffer shows this at its start:
>
>   key             binding
>   ---             -------
>
>   0 .. 9	digit-argument
>   e		tar-extract  (currently shadowed by ‘View-exit’)
>   f		tar-extract
>
>   C-d		tar-flag-deleted
>   RET		tar-extract
>     (this binding is currently shadowed)
>   C-n		tar-next-line
>   C-p		tar-previous-line
>   SPC		tar-next-line
>     (this binding is currently shadowed)
>   C		tar-copy
>     (this binding is currently shadowed)
>
> Note how the shadowing of 'e' is described with the command that
> shadows it, but the shadowing of RET, SPC, and 'C' isn't.  Why is
> that?  Is that a separate bug?

It is a separate bug, I think.  The "currently shadowed part" is new in
commit fb9326b45c76, but it was never fixed for the second case.

Which of the two messages is shown has to do with whether or not this is
a regular keymap or a sparse keymap.  They were always handled slightly
differently, but now we have the changed message for one of them that
makes this visible.

> for some reason bug#9293 discussed only a small part of the *Help*
> display and never looked beyond that.

I overlooked the case you mention, indeed.