From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#14086: 24.3.50; `substitute-command-keys': inappropriate "(that binding is currently shadowed by another mode)" Date: Sat, 3 Oct 2020 22:00:39 -0700 (PDT) Message-ID: References: <0FF2F801815441C3B5385CE3202E16A0@us.oracle.com> <87364basd9.fsf@gnus.org> <09025e7c-3f7b-4e39-b573-776fba837ceb@default> <87o8li933g.fsf@web.de> <726d8e32-8682-4d03-a558-c02b31c5e679@default> <87k0w690gg.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7268"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 14086@debbugs.gnu.org To: Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 04 07:02:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kOw9y-0001kZ-RS for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 04 Oct 2020 07:02:10 +0200 Original-Received: from localhost ([::1]:44640 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kOw9x-0005qS-PA for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 04 Oct 2020 01:02:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36392) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kOw9q-0005qG-NH for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2020 01:02:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33256) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kOw9q-0001gk-Do for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2020 01:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kOw9q-0001PS-Bu for bug-gnu-emacs@gnu.org; Sun, 04 Oct 2020 01:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Oct 2020 05:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14086 X-GNU-PR-Package: emacs Original-Received: via spool by 14086-submit@debbugs.gnu.org id=B14086.16017876695360 (code B ref 14086); Sun, 04 Oct 2020 05:02:02 +0000 Original-Received: (at 14086) by debbugs.gnu.org; 4 Oct 2020 05:01:09 +0000 Original-Received: from localhost ([127.0.0.1]:44802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kOw8l-0001Nj-41 for submit@debbugs.gnu.org; Sun, 04 Oct 2020 01:01:09 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:56872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kOw8i-0001NU-Jl for 14086@debbugs.gnu.org; Sun, 04 Oct 2020 01:00:53 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09450j28080225; Sun, 4 Oct 2020 05:00:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=fuSfqZE2LE23k4SxLHXn/wfaefmHsS+uE6+5CdrvHQI=; b=FOu2F4QMwLXa48o0Oob9H9m8HIFenXE59pkH0bCqG23+zjJr0XhnEZ++AudlB1qVLVKi quT2nGM7cqUu2OoAfbqNAC2rOGGg1y1T0sQ2OwZbrzneQZPqQI0GPTAtMc89nEsRKZzx SzLeE8dP6+AcO2L4UJfS2uhP6GWHs2XE9gUe7jYSh15uxKnLjv62aUGb0P7c0RcQMFnK 80xcQ9DjhndnHTI6xmxCXR6oYy3RymQZHIL0gecupkLgzRqbJO7KqsCer1rgOi8xU+N/ S/Y+0xF/VvkUTQSSG5pjAD9/T0kSW4m3RkMRP+y1LAJgcnkty6p1tTu1kj9aRUkrd5oG dA== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 33xhxmhq03-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 04 Oct 2020 05:00:45 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09450ekb043878; Sun, 4 Oct 2020 05:00:45 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 33y36v6xhe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 04 Oct 2020 05:00:45 +0000 Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 09450emb002741; Sun, 4 Oct 2020 05:00:41 GMT In-Reply-To: <87k0w690gg.fsf@web.de> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5056.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9763 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 adultscore=0 bulkscore=0 spamscore=0 malwarescore=0 suspectscore=0 phishscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010040037 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9763 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 malwarescore=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 adultscore=0 clxscore=1015 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2010040037 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:189740 Archived-At: > > 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? >=20 > 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. >=20 > 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.