bug#40725: 27.0.91; Tutorial reports false positive key rebindings

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: 40725@debbugs.gnu.org
> Date: Mon, 20 Apr 2020 23:19:46 +0100
> 
> The function in question, tutorial--find-changed-keys, is only ever
> passed the defconst tutorial--default-keys as argument.

Yes, and one of the aspects I thought about was whether this change
could make use less future-proof, if more keys are added.

> In fact, the tutorial doesn't mention C-c at all, but apparently
> it's included in tutorial--default-keys just because it's an
> otherwise common prefix.

AFAIU from the code, the main consideration with C-c is when the user
turns on the CUA mode, not because it's a common prefix.  So maybe we
should narrow the test to only make sure CUA rebindings get caught?

> > How do we distinguish the case where _all_ of the subcommands were
> > rebound, for example?
> 
> I don't think the current logic tries to handle that either, does it?

Well, we are trying to improve the current logic, aren't we?

> > Also, don't we have some prefixes that for the purposes of the
> > tutorial must not have _any_ of its subcommands rebound?
> 
> Hm, I don't know.  Did you have any examples in mind?  The only prefixes
> I see used in the tutorial are C-x, C-h, and Meta/ESC.
> 
> AFAICT if a command-binding pair isn't listed in tutorial--default-keys,
> then C-h t won't complain about it being rebound.  For example, you can
> rebind C-x k (which IS mentioned in the tutorial) and C-h t won't notice
> at all.

So maybe we should add that, to make the test more thorough?

> I can open another bug report for extending tutorial--default-keys to
> detect changes to all default key bindings used in the tutorial, but for
> now I think the proposed patch fixes the issue at hand without making
> things worse.

I just want to make sure we don't do anything that could cause subtle
problems.  Bugs while reading the tutorial are the worst kind, for
obvious reasons.

Thanks.