From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.devel Subject: Re: bug#49265: [External] : bug#49265: 28.0.50; repeat mode feature request Date: Tue, 26 Oct 2021 12:06:28 +0200 Message-ID: <87pmrsqevv.fsf@gmail.com> References: <87czs53aei.fsf.ref@aol.com> <87czs53aei.fsf@aol.com> <87h7hh6o8t.fsf@mail.linkov.net> <87wnqcv25h.fsf@mail.linkov.net> <874kdfekr8.fsf@gmail.com> <87r1gj6say.fsf@mail.linkov.net> <87r1cdz72i.fsf@gmail.com> <875ytn8ufp.fsf@mail.linkov.net> <877de2zeqk.fsf@gmail.com> <87sfwqgrt4.fsf@mail.linkov.net> <87y26ixkb8.fsf@gmail.com> <87tuh5lgc7.fsf@mail.linkov.net> <87bl3dscup.fsf@gmail.com> <87sfwp9zs8.fsf@igel.home> <87sfwpuh1g.fsf@mail.linkov.net> <87tuh4ri45.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15658"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Ergus , Stefan Kangas , emacs-devel , Andreas Schwab , Juri Linkov , Drew Adams To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 26 12:07:11 2021 Return-path: Envelope-to: ged-emacs-devel@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 1mfJMN-0003xE-MK for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 12:07:11 +0200 Original-Received: from localhost ([::1]:41868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfJML-00068v-IT for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 06:07:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48000) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfJLl-0005U7-Rd for emacs-devel@gnu.org; Tue, 26 Oct 2021 06:06:33 -0400 Original-Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:54020) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mfJLk-0007WK-36 for emacs-devel@gnu.org; Tue, 26 Oct 2021 06:06:33 -0400 Original-Received: by mail-wm1-x336.google.com with SMTP id j205so12837961wmj.3 for ; Tue, 26 Oct 2021 03:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=rRplNuGSOC9D+QYBdFQ2rLjWXkDRpH+UO0rTTHeRGgc=; b=DMsYS8TYJgROg2KViXDjqlZAw1OqWr1Z14xn/CgPdAUrRYBTjRzwCnMUVJJFdVFOuP EeaUgmhD6lc07xkR5++4KnctcVjEamp00rAcDa7iNG9HiWwT8ZAkh4gjBeIBHP3fTaEZ 1skHW2j0zYAUv8ahkv/I/Wxn9rXPIqFPE4pu79cfJSVoypBxSpvVBQc7HOX2dwwocdHi t0W6y6S78bH50we8EHXb+DuNFiJMmuZrCqzR8pf1FtIFG6cninV9aya4JHnQPRpbJnNT g5RbNAk4vlMxgD/kGEzys9NFmthRoWWhBMgumdw1Th7bypMNwvB0lWNoyAHWapiC4JqF Q5sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=rRplNuGSOC9D+QYBdFQ2rLjWXkDRpH+UO0rTTHeRGgc=; b=uWqicnXz/HIUFjToUpRB/O8rSUn7dqRMYUSWpwLOdecMqf3OK0DfL7sorYEalIoy/H tP2ljTF0exAvvmAcHHf4kzD0JnX4zHkpT9eAzHLvjS+LnGDriYe5Ql7WqLG4u35vOh/h g69w38dteoi1ryAtNRsCijmps5Ql49fO23iMa1JTk5aVKj1e9TlNDJffGDc2PgtQC4QL w2b2dciGgsgoIpvUuF9181aiE5e6lM80jr0TtqWPfRjXKmurlq//7CEuVCKD0ymrVO6S csUtDgbH/+iRjSZ6uoAy996ezA0bBP9t+7y/vjsA/EGAUW7jGt+Rci/dxJmrIcZ+QHtC hZEg== X-Gm-Message-State: AOAM531/FsPREZg59JSXHY5LAU0U5UyrBXw4qbAJEZQWv6T5teK/HR3Q +L6ejf9ELSJibTp7kmnOafPhSgvjUBI= X-Google-Smtp-Source: ABdhPJyYjqW+65HD8sbbUcucMS1wHAqpkR3xxoYUai3Hzga4ZXQIG+rGrbMOjNANFd9TufsePQmd9g== X-Received: by 2002:a05:600c:154f:: with SMTP id f15mr27636859wmg.195.1635242789953; Tue, 26 Oct 2021 03:06:29 -0700 (PDT) Original-Received: from rltb ([82.66.8.55]) by smtp.gmail.com with ESMTPSA id l2sm14346793wrx.68.2021.10.26.03.06.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Oct 2021 03:06:29 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Mon, 25 Oct 2021 16:57:19 -0400") Received-SPF: pass client-ip=2a00:1450:4864:20::336; envelope-from=rpluim@gmail.com; helo=mail-wm1-x336.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:277830 Archived-At: >>>>> On Mon, 25 Oct 2021 16:57:19 -0400, Stefan Monnier said: Stefan> The \\<...> doesn't override all other maps, so the `undo` comm= and is Stefan> still found to be bound to `C-x u` in the global map. >> Right. I think it should look *only* in the specified map, otherwise >> what's the point of specifying it? Stefan> The common case is to specify the keymap that will likely be ac= tive when Stefan> the command is used. OK, so I guess that pleads for a fallback to the current behaviour. Stefan> Maybe you're right that we shouldn't look elsewhere, but I'd be Stefan> surprised if there aren't docstrings that rely on the current b= ehavior. That may be true, and I can=CA=BCt think of an easy way of finding them. Stefan> But I agree that maybe `where-is-internal` could be told Stefan> here to give precedence to bindings found in the Stefan> \\<...> map. >>=20 >> `where-is-internal' is not the issue. If you pass it (list keymap) it >> will look only in 'keymap'. But substitute-command-keys passes it >> 'keymap', which allows it to look in the global map as well. >>=20 >> Perhaps something like this? Stefan> Sounds about right, tho it disregards other keymaps than `keyma= p` and Stefan> `global-map`. Maybe we should do Stefan> (or (where-is-internal fun (list keymap) t) Stefan> (where-is-internal fun nil t)) Stefan> instead to avoid this problem. I think the minimal change from the current behaviour would be this, since 'keymap' starts out as 'overriding-local-map', but then can get set to 'nil' or a specific keymap based on the contents of the string. Or we could add an optional argument to 'substitute-command-keys' to mean 'only look in MAPVAR'. diff --git a/lisp/help.el b/lisp/help.el index 9666ef9805..55e58e20e5 100644 --- a/lisp/help.el +++ b/lisp/help.el @@ -1124,7 +1124,9 @@ substitute-command-keys (delete-char 2) (let* ((fun (intern (buffer-substring (point) (1- end-poin= t)))) (key (with-current-buffer orig-buf - (where-is-internal fun keymap t)))) + (or + (where-is-internal fun (list keymap) t) + (where-is-internal fun keymap t))))) ;; If this a command remap, we need to follow it. (when (and (vectorp key) (> (length key) 1) @@ -1132,7 +1134,9 @@ substitute-command-keys (symbolp (aref key 1))) (setq fun (aref key 1)) (setq key (with-current-buffer orig-buf - (where-is-internal fun keymap t)))) + (or + (where-is-internal fun (list keymap) t) + (where-is-internal fun keymap t))))) (if (not key) ;; Function is not on any key. (let ((op (point))) Robert --=20