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

[Eli Zaretskii <eliz@gnu.org>]

> 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.

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.  I also left alone
parts of the code where Stefan proposed changes of stylistic
character.

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?  (This display was there even before my
changes, so I don't think the latest changes were the culprit; but for
some reason bug#9293 discussed only a small part of the *Help* display
and never looked beyond that.)

Thanks.