bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

I do this for each of the minibuffer completion maps as MAP:
 
 (define-key MAP (kbd "M-r") 'icicle-roundup)
 
I then do this, for example:
 
 (substitute-command-keys "\\{minibuffer-local-completion-map}")
 
I see the keys that are defined in this map, including this one:
 
 M-r             icicle-roundup
 
But near the end of the listing (not at all near that entry), I see this
other entry for `M-r':
 
 M-r             previous-matching-history-element
   (that binding is currently shadowed by another mode)
 
That makes no sense, or is at least misleading.  There is no special
"mode" that I am aware of that is involved here, for one thing.  And I
don't see how the `previous-matching-history-element' binding is
"shadowed", whether by "another mode" or any other way.  `M-r' is simply
bound to `icicle-roundup' in this keymap - it is not bound to
`previous-matching-history-element' in this map, AFAIK.
 
Seems like a bug to me.  At the very least it is unhelpful and
misleading for a user who sees this.  (Not to mention the fact that this
extra info, if you think it serves a purpose, is far from the first
`M-r' entry, so a user will likely see one or the other but not both
together (unless the keymap has few keys in it).
 
I cannot see why we should ever have two different entries listed for the same
key.  And especially one that is so misleadingly described.  And especially with
the two entries far apart.
 
 
 
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2013-03-23 on VBOX
Bzr revision: 112115 eliz@gnu.org-20130323093300-rjs0dgskxm9u0ya4
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/emacs/libs/libXpm-3.5.10/include -IC:/emacs/libs/libXpm-3.5.10/src
 -IC:/emacs/libs/libpng-dev_1.4.3-1_win32/include
 -IC:/emacs/libs/zlib-dev_1.2.5-2_win32/include
 -IC:/emacs/libs/giflib-4.1.4-1-lib/include
 -IC:/emacs/libs/jpeg-6b-4-lib/include
 -IC:/emacs/libs/tiff-3.8.2-1-lib/include
 -IC:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
 -IC:/emacs/libs/gnutls-3.1.10-w32/include
 -IC:/emacs/libs/libiconv-1.14-2-mingw32-dev/include'
 

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> But near the end of the listing (not at all near that entry), I see this
> other entry for `M-r':
>
>  M-r             previous-matching-history-element
>    (that binding is currently shadowed by another mode)

Yeah, kinda awkward way of putting it.  What about just

(binding currently shadowed)

?

> That makes no sense, or is at least misleading.  There is no special
> "mode" that I am aware of that is involved here, for one thing.  And I
> don't see how the `previous-matching-history-element' binding is
> "shadowed", whether by "another mode" or any other way.  `M-r' is simply
> bound to `icicle-roundup' in this keymap - it is not bound to
> `previous-matching-history-element' in this map, AFAIK.
>
> Seems like a bug to me.  At the very least it is unhelpful and
> misleading for a user who sees this.  (Not to mention the fact that this
> extra info, if you think it serves a purpose, is far from the first
> `M-r' entry, so a user will likely see one or the other but not both
> together (unless the keymap has few keys in it).

I think it sounds useful to list bindings that would normally be on the
map unless something had redefined the key.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

>  M-r             previous-matching-history-element
>    (that binding is currently shadowed by another mode)

The wording was introduced by Richard in 2006:

commit 5615dcc03b721ea3a4d619fe8c6f9a4232193c3d
Author: Richard M. Stallman <rms@gnu.org>
Date:   Tue Apr 18 20:58:59 2006 +0000

    (describe_map): Make "shadowed" warning more verbose.

diff --git a/src/keymap.c b/src/keymap.c
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -3375,2 +3375,2 @@
-	  insert_string ("  (shadowed)");
+	  insert_string ("\n  (that binding is currently shadowed by another mode)");
 	  SET_PT (PT + 1);



-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
> >  M-r             previous-matching-history-element
> >    (that binding is currently shadowed by another mode)

I guess this happens because `minibuffer-local-completion-map', where
Drew made the binding, has as parent map `minibuffer-local-map', whose
binding (indeed) gets shadowed.

Dunno whether the different ways of shadowing can be easily
distinguished.  But I agree that the wording is misleading.

Maybe we should just say "that binding is currently shadowed".


Michael.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> "Drew Adams" <drew.adams@oracle.com> writes:
>>
>> >  M-r             previous-matching-history-element
>> >    (that binding is currently shadowed by another mode)
>
> I guess this happens because `minibuffer-local-completion-map', where
> Drew made the binding, has as parent map `minibuffer-local-map', whose
> binding (indeed) gets shadowed.
>
> Dunno whether the different ways of shadowing can be easily
> distinguished.  But I agree that the wording is misleading.
>
> Maybe we should just say "that binding is currently shadowed".

Or "(this binding is currently shadowed)"?  The "that" is the oddest
part of the sentence.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 29 Apr 2016 14:26:54 +0200
> Cc: 14086@debbugs.gnu.org
> 
> Or "(this binding is currently shadowed)"?  The "that" is the oddest
> part of the sentence.

Not in my eyes, it isn't.  It is very clear and correct English.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

Dunno how anyone could argue that this is not a bug.
AFAICT, there is no shadowing going on here (in the
example given).

And beyond the fact that this seems incorrect for the
example given, to repeat some of the original bug report:

  I cannot see why we should ever have two different entries
  listed for the same key.  And especially one that is so
  misleadingly described.  And especially with the two entries
  far apart.

To me this is a bug, through and through.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> Dunno how anyone could argue that this is not a bug.
> AFAICT, there is no shadowing going on here (in the
> example given).

It might be because you provided no reproducible test case in your bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Lars Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> But near the end of the listing (not at all near that entry), I see this
> other entry for `M-r':
>
>  M-r             previous-matching-history-element
>    (that binding is currently shadowed by another mode)
>
> That makes no sense, or is at least misleading.  There is no special
> "mode" that I am aware of that is involved here, for one thing.  And I
> don't see how the `previous-matching-history-element' binding is
> "shadowed", whether by "another mode" or any other way.  `M-r' is simply
> bound to `icicle-roundup' in this keymap - it is not bound to
> `previous-matching-history-element' in this map, AFAIK.

The test case is this:

(define-key minibuffer-local-completion-map (kbd "M-r") 'icicle-roundup)
(substitute-command-keys "\\{minibuffer-local-completion-map}")

"key             binding
---             -------

C-g		abort-recursive-edit
[...]
M-r		icicle-roundup
[...]
M-r		previous-matching-history-element
  (that binding is currently shadowed by another mode)
"

That is pretty confusing -- I didn't even know that you could have the
same key binding twice in a keymap?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Michael Heerdegen]

Lars,

seems you treated this in 64d2e5a7a "Make shadowing warning in
describe_map less confusing".  Contended enough to close this report?

Thanks,

Michael.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

> > But near the end of the listing (not at all near that entry), I see this
> > other entry for `M-r':
> >
> >  M-r             previous-matching-history-element
> >    (that binding is currently shadowed by another mode)
> >
> > That makes no sense, or is at least misleading.  There is no special
> > "mode" that I am aware of that is involved here, for one thing.  And I
> > don't see how the `previous-matching-history-element' binding is
> > "shadowed", whether by "another mode" or any other way.  `M-r' is simply
> > bound to `icicle-roundup' in this keymap - it is not bound to
> > `previous-matching-history-element' in this map, AFAIK.
> 
> The test case is this:
> 
> (define-key minibuffer-local-completion-map (kbd "M-r") 'icicle-roundup)
> (substitute-command-keys "\\{minibuffer-local-completion-map}")
> 
> "key             binding
> ---             -------
> 
> C-g		abort-recursive-edit
> [...]
> M-r		icicle-roundup
> [...]
> M-r		previous-matching-history-element
>   (that binding is currently shadowed by another mode)
> "
> 
> That is pretty confusing -- I didn't even know that you could have the
> same key binding twice in a keymap?

I'm guessing that comes from `bindings.el' binding `M-r' to `previous-matching-history-element' in `minibuffer-local-map', and Icicles binding `M-r' to `icicle-roundup' in `minibuffer-local-completion-map'.  And this is true:

(eq minibuffer-local-map
    (keymap-parent minibuffer-local-completion-map))

I'm guessing that's what all the "shadowing" is about.  `icicle-roundup' is the actual binding, in `minibuffer-local-completion-map'.  Why, in a listing of `minibuffer-local-completion-map', we show the other command as also being bound to `M-r', I don't know.  I don't mean how we do that, but why - for users?

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> (eq minibuffer-local-map
>     (keymap-parent minibuffer-local-completion-map))
>
> I'm guessing that's what all the "shadowing" is about.

Yes, I've found that some minutes ago as well, just to see that it had
been clear even before Lars asked the question you responded to.  He
even had changed the text to say just "this binding is shadowed" long
before.  I think he just forgot to close the report and restarted
working on it from the start much later.

> `icicle-roundup' is the actual binding, in
> `minibuffer-local-completion-map'.  Why, in a listing of
> `minibuffer-local-completion-map', we show the other command as also
> being bound to `M-r', I don't know.  I don't mean how we do that, but
> why - for users?

I think so, yes.

Michael.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

> > `icicle-roundup' is the actual binding, in
> > `minibuffer-local-completion-map'.  Why, in a listing of
> > `minibuffer-local-completion-map', we show the other command as also
> > being bound to `M-r', I don't know.  I don't mean how we do that, but
> > why - for users?
> 
> I think so, yes.

Not sure what you're saying.  Why should we show the
shadowed binding?  That's the question I was asking
there.  How it comes to be shown was the subject
above that in the post.  But should it be shown?
If so, why?

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> Not sure what you're saying.  Why should we show the
> shadowed binding?  That's the question I was asking
> there.  How it comes to be shown was the subject
> above that in the post.  But should it be shown?
> If so, why?

It's debatable, sure.  But sometimes it's useful info, don't you think?
If you unbind the shadowing key to nil, the other binding will take
effect, so in that sense it is meaningful to the behavior of the keymap.

Do you think we should not list shadowed bindings (and why)?

Michael.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

> > Not sure what you're saying.  Why should we show the
> > shadowed binding?  That's the question I was asking
> > there.  How it comes to be shown was the subject
> > above that in the post.  But should it be shown?
> > If so, why?
> 
> It's debatable, sure.  But sometimes it's useful info, don't you think?
> If you unbind the shadowing key to nil, the other binding will take
> effect, so in that sense it is meaningful to the behavior of the keymap.
> 
> Do you think we should not list shadowed bindings (and why)?

No, I was just asking the question - open.

You provided a reason to show shadowed bindings.
That's good enough for me - makes sense.

But it only makes sense if someone can understand.
What's missing is something, somewhere, that tells
you what it means to show one binding for a key
with no special mention (no mention of shadowing)
and another binding for the same key, with just a
mention that it is shadowed by some other key.

What shadowing means needs to be conveyed somehow,
somewhere.  And it would be better to list the
command that shadows the shadowed command/binding.

As an analogy, if some function or variable is an
alias for another, the help tells you that.  Or if
you ask for the value of a variable in a buffer
where it's local, the help tells you the local
value and lets you know what the global value is.

If we list an `M-r' binding to
`previous-matching-history-element' that's shadowed
by an `M-r' binding to `icicle-roundup' then it
would be good to say that the former is shadowed by
the latter.  Currently we say only that it is
shadowed by another "mode".

It would be even better if we said what keymap
the shadowed binding is bound in, and what keymap
the shadowing binding is bound in.  Dunno whether
that's always possible, but it would help.

The first thing that's missing is what "shadow"
means - that wasn't clear to me at all.  I think
it would help, even if we didn't explain that
term, if we explicitly said which binding (e.g.
`icicle-roundup') does the shadowing.  With that
info a user might be able to guess what "shadow"
means.

What's most important is that it's clear to a user
that ONLY the shadowing binding is in effect.
Mentioning the shadowed binding is only extra info
about what could happen if the shadowing binding
weren't in effect.  (Like what would happen if a
buffer-local value were removed.)

Another thing that hampers understanding is the
order of the bindings listed.  Both bindings of
`M-r' should be listed next to each other.

I'm looking at the output of `describe-keymap'
for `minibuffer-local-completion-map', and the
order is not clear/useful, I think.

[I see the same thing using either my version of
`describe-keymap' or the version added to Emacs 28
(bug #30660).]

But #14086 is about the unclear help when it comes
to listing shadowed bindings.  I agree that it can
be useful to list such bindings, but only if we
can make clear what they mean.  The gain is minor,
and not worth it if we can't make this clear, I
think.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> seems you treated this in 64d2e5a7a "Make shadowing warning in
> describe_map less confusing".  Contended enough to close this report?

Yeah I think so; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

> > seems you treated this in 64d2e5a7a "Make shadowing warning in
> > describe_map less confusing".  Contended enough to close this report?
> 
> Yeah I think so; closing.

I don't have a way of seeing the change you made.
Can you please describe it here or include the
patch here?  Usually a patch is included in the
bug thread, and it's then directly accessible
from the thread on debugs.gnu.org.  A reference
like "64d2e5a7a" means nothing to me.

Wrt the confusion that this bug is about:

I think that one of the following things should
happen, or something else that takes care of the
same problem of listing the same key twice, and
not together, and with no labeled grouping of
the different keymaps (parent, child):

* List the duplicate keys next to each other, with
  the unshadowed one first.

  That makes clear (a) that shadowing occurs, and
  (b) which shadows the other (given the note for
  the shadowed one).

  It doesn't, however, by itself make clear what
  shadowing is, and that there are multiple keymaps
  involved, with inheritance causing the "shadowing".

OR ELSE

* List the keys of a given keymap (parent or child)
  together, as is apparently (?) done now, but label
  them as such.  IOW, label each of the keymap listings,
  and say which keymap's keys shadow the other's.

  And clearly label a shadowed key binding with the
  command that shadows it.  And preferably include a
  link to that command's line in the listing (since
  it is far away, in the other keymap's listing).

If neither of those, or similar, is done, then I don't
think this bug should be closed.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Eli Zaretskii]

> Date: Sun, 4 Oct 2020 10:40:55 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 14086@debbugs.gnu.org
> 
> > > seems you treated this in 64d2e5a7a "Make shadowing warning in
> > > describe_map less confusing".  Contended enough to close this report?
> > 
> > Yeah I think so; closing.
> 
> I don't have a way of seeing the change you made.
> Can you please describe it here or include the
> patch here?  Usually a patch is included in the
> bug thread, and it's then directly accessible
> from the thread on debugs.gnu.org.  A reference
> like "64d2e5a7a" means nothing to me.

It doesn't have to mean nothing.  You can point your browser at

  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=64d2e5a7a

and se the changes.  Note that everything in that URL is fixed, apart
from the commit ID, which is what Lars mentioned.  So that ID is a
unique ID of the changeset, and you can always find it as above.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

> > > > seems you treated this in 64d2e5a7a "Make shadowing warning in
> > > > describe_map less confusing".  Contended enough to close this report?
> > >
> > > Yeah I think so; closing.
> >
> > I don't have a way of seeing the change you made.
> > Can you please describe it here or include the
> > patch here?  Usually a patch is included in the
> > bug thread, and it's then directly accessible
> > from the thread on debugs.gnu.org.  A reference
> > like "64d2e5a7a" means nothing to me.
> 
> It doesn't have to mean nothing.  You can point your browser at
> 
> https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git/commi
> t/?id=64d2e5a7a__;!!GqivPVa7Brio!IsQgpRqg8hn3L0tWsgCncaPbIHrmy6RrrNCHsgA-
> PbKAeR3z2EbhlmIutmY38TT0$
> 
> and se the changes.  Note that everything in that URL is fixed, apart
> from the commit ID, which is what Lars mentioned.  So that ID is a
> unique ID of the changeset, and you can always find it as above.

That's good to know.  Thank you.

I suppose I can bookmark that URL, and then, if
I ever need to point my browser to a given commit ID,
I can go there and then edit the "id" value to that ID.

That's hardly something I'd want to have to do, I'm afraid.

In any case, I think the patch, or a good description - not
just a commit ID -belongs in this bug thread explicitly.  
___

Beyond that general consideration:

When I go to the URL you provided I don't recognize anything
that has anything to do with this bug.  I certainly don't
see "Make shadowing warning in describe_map less confusing".

What am I missing?

Perhaps I'm just dense.  In any case, I do think the
description/patch belongs in this bug thread.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> Beyond that general consideration:
>
> When I go to the URL you provided I don't recognize anything
> that has anything to do with this bug.  I certainly don't
> see "Make shadowing warning in describe_map less confusing".
>
> What am I missing?

You are missing the correct id.  That's because I accidentally copied
the id of the parent commit, my fault, sorry.

The correct commit id is "764bad713e", so here you go:

  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=764bad713e

This interface really doesn't look bad, you can even search commit
messages of the whole repository, and the result appears much faster
than on my local computer.

Michael.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Eli Zaretskii]

> Date: Sun, 4 Oct 2020 12:13:13 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: larsi@gnus.org, michael_heerdegen@web.de, 14086@debbugs.gnu.org
> 
> > It doesn't have to mean nothing.  You can point your browser at
> > 
> > https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git/commi
> > t/?id=64d2e5a7a__;!!GqivPVa7Brio!IsQgpRqg8hn3L0tWsgCncaPbIHrmy6RrrNCHsgA-
> > PbKAeR3z2EbhlmIutmY38TT0$
> > 
> > and se the changes.  Note that everything in that URL is fixed, apart
> > from the commit ID, which is what Lars mentioned.  So that ID is a
> > unique ID of the changeset, and you can always find it as above.
> 
> That's good to know.  Thank you.
> 
> I suppose I can bookmark that URL, and then, if
> I ever need to point my browser to a given commit ID,
> I can go there and then edit the "id" value to that ID.
> 
> That's hardly something I'd want to have to do, I'm afraid.

Why not? it is very simple.  In general, if you want to be involved
with Emacs development (or any software development, really) nowadays,
you are expected to access the repository in some way and be able to
review changes given their commit ID.  Not having a local checkout of
the repository is already quite unusual; refusing to even go to the
Web interface of the repository is more than brow-raising.

> In any case, I think the patch, or a good description - not
> just a commit ID -belongs in this bug thread explicitly.  

That is extra burden for people who develop and maintain Emacs.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

> > When I go to the URL you provided I don't recognize anything
> > that has anything to do with this bug.  I certainly don't
> > see "Make shadowing warning in describe_map less confusing".
> >
> > What am I missing?
> 
> You are missing the correct id.  That's because I accidentally copied
> the id of the parent commit, my fault, sorry.
> 
> The correct commit id is "764bad713e", so here you go:
> 
> https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git/commi
> t/?id=764bad713e__;!!GqivPVa7Brio!LRyBzbGQgePdEC581vAw7oEXMplMN-
> 6oGif6U9_pUeV9E-UD8FDilGMjYXUjd4dq$

Thanks, Michael.
___

The fix doesn't fix the problem at all, unfortunately.
At least it removes mention of "mode".  It doesn't make
clear what shadowing is or what shadows that binding.

Presumably it's shadowed by a binding in a descendant
(e.g. child) keymap.  (Is that the only possibility?)
If so, it should at least say that.

But I've said more about what I think a real fix should
be in previous messages.

> This interface really doesn't look bad, you can even search commit
> messages of the whole repository, and the result appears much faster
> than on my local computer.

I don't understand.  What interface?

Did you mean that GIT index: emacs.git web page?
If so, how to use it?  I tried inserting 764bad713e
into the search field and got nothing.  See attached
screenshot.

[-- Attachment #2: throw-git-savannah-emacs-git.png --]
[-- Type: image/png, Size: 58421 bytes --]

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> If so, how to use it?  I tried inserting 764bad713e
> into the search field and got nothing.

The search field searches log messages by default, so you can enter a
bug number for example.

But commit id searching also works: if you select "range" (button in
front of the field) and enter the id, the topmost commit presented is
the one with the given id.

Any other questions?

Michael.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

> > If so, how to use it?  I tried inserting 764bad713e
> > into the search field and got nothing.
> 
> The search field searches log messages by default, so you can enter a
> bug number for example.
> 
> But commit id searching also works: if you select "range" (button in
> front of the field) and enter the id, the topmost commit presented is
> the one with the given id.

I see, thanks.  So pick "range" in the dropdown to the left of the search field.

Thx.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> Currently we say only that it is shadowed by another "mode".

Isn't that wording what the commit that we had pointed you at changed?
The text doesn't speak about a "mode" any more.

And is the word "shadowed" really unclear?  It's used in the manual, but
not officially defined.  To me it was clear from the beginning what it
means.

I agree that it could be useful to tell what causes the shadowing,
though there are ways for the user to find out (e.g. C-h k).

Michael.

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Drew Adams]

> > Currently we say only that it is shadowed by another "mode".
> 
> Isn't that wording what the commit that we had pointed you at changed?
> The text doesn't speak about a "mode" any more.

Yes.  You replied to a message from Saturday, where I
was referring to the state before the fix (I hadn't
yet seen the fix).

See my mail from this morning, which speaks about the
after-fix state.

> And is the word "shadowed" really unclear?  It's used in the manual, but
> not officially defined.  To me it was clear from the beginning what it
> means.

It can be understood, yes.  The problem is that what
shadows the key is unclear.  And the listing of keys
is apparently by keymap, with no indication of that
or any indication of which keymap is parent etc.

Listing (grouping) by keymaps is OK, if that's made clear.

Alternatively, listing by keys would also be OK.  In
that case, multiple bindings for the same key would
be listed next to each other, and it's enough to say,
for a given key, that it's shadowed - because then it's
obvious which key does the shadowing.

But in that alternative listing it's not clear why
this one shadows that one, because there's no mention
or identification of their keymaps and their relation.

> I agree that it could be useful to tell what causes the shadowing,
> though there are ways for the user to find out (e.g. C-h k).

Please see my mail from this morning about this.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14086#70

bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)"

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Tue, 06 Oct 2020 23:20:23 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 14086@debbugs.gnu.org
> 
> Drew Adams <drew.adams@oracle.com> writes:
> 
> > Currently we say only that it is shadowed by another "mode".
> 
> Isn't that wording what the commit that we had pointed you at changed?
> The text doesn't speak about a "mode" any more.
> 
> And is the word "shadowed" really unclear?

It isn't unclear to me, FWIW.