From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.bugs Subject: bug#50430: [External] : bug#50430: windmove bindings now override org-read-date Date: Mon, 6 Sep 2021 15:54:51 -0700 Message-ID: References: <87zgsp949o.fsf@posteo.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008e4ca605cb5b8bdb" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25937"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip Kaludercic , "50430@debbugs.gnu.org" <50430@debbugs.gnu.org> To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 07 00:56:15 2021 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 1mNNXD-0006Ym-HA for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Sep 2021 00:56:15 +0200 Original-Received: from localhost ([::1]:60066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mNNXC-000548-Gf for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Sep 2021 18:56:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48646) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mNNX1-00053x-4P for bug-gnu-emacs@gnu.org; Mon, 06 Sep 2021 18:56:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43174) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mNNWz-0005E4-UY for bug-gnu-emacs@gnu.org; Mon, 06 Sep 2021 18:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mNNWz-0001QU-P1 for bug-gnu-emacs@gnu.org; Mon, 06 Sep 2021 18:56:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Radon Rosborough Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Sep 2021 22:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50430 X-GNU-PR-Package: emacs Original-Received: via spool by 50430-submit@debbugs.gnu.org id=B50430.16309689355445 (code B ref 50430); Mon, 06 Sep 2021 22:56:01 +0000 Original-Received: (at 50430) by debbugs.gnu.org; 6 Sep 2021 22:55:35 +0000 Original-Received: from localhost ([127.0.0.1]:54718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mNNWY-0001Pl-Nc for submit@debbugs.gnu.org; Mon, 06 Sep 2021 18:55:34 -0400 Original-Received: from mail-ot1-f43.google.com ([209.85.210.43]:33764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mNNWX-0001PZ-6s for 50430@debbugs.gnu.org; Mon, 06 Sep 2021 18:55:33 -0400 Original-Received: by mail-ot1-f43.google.com with SMTP id c42-20020a05683034aa00b0051f4b99c40cso10516137otu.0 for <50430@debbugs.gnu.org>; Mon, 06 Sep 2021 15:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KjY5Ci+ZpeP/JEq0Wlt2sqrRoycC4UK9ZwFPyZQr1qM=; b=buUooTNVLJiJxm4qy+qJDS0OwBT6TsqmGQGa3mQXQ5h7mx1fDUGJWVNxkvEUKBJqgR jr8TOJJVjsvuNlsLx93oVRnamYnaL01RfIkwSVSDFWN3SF43rGbQu80tWrcuXGMEDaRf bPBb3ITLMA5uqfszuWLFFwtRLHTaIeO9gnQv3dsaDMdMPKTToLWgPDVw4Gq3OfL80ccz sDjmmnNz+8GdISH9JvNyoR514YoNbzzptosowkBAaFJBXfSJGhRtoQcWIracZP1kGJ5y c06rlzONXta0xtN1Gct5wvj8Pt8iAMg7CZ7cvT/dZ0MWB86peKwJF3BK2Ukk96jq/oHj XJYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KjY5Ci+ZpeP/JEq0Wlt2sqrRoycC4UK9ZwFPyZQr1qM=; b=bikarZk39AeyFoBAevoT2kmF4i7ipzovkAFEcVQD0ltkOCTB6O/9ZMJ2NUKf/TyVLi LHI9aYhACny9RngXm4up/1YkpcYWGIjXEb88NA1tVMTrZ0IIeYRkdlYv3Bhxb8ENdTvw da+RjNgFY19q5zpxX/99sjRWl2pvBR+s9pZrMefhwC/pF6eSpiDYhE+cof5xxjrkhWiu rzL48HObu5pz3F0BaJ2KGNkfi4t8yxkDDKIcDny/NxSVr1EbbrLpothx/5iqMkL8pJqS 5BpihfTNw2bzDltvVxUsY+cNx6h/e3cwWKR7rEhShd3ge74yJY7Mpn/c015ND+TSQBQs T6aQ== X-Gm-Message-State: AOAM532BW8wlIdOYBqI/iK7UOEcmBdaCp6MCY7TtdDcO1xxdFkjMSdjm mvJWYEhLVNdXSlHkavKAw0hUBr+DcS+ppoA/2z8= X-Google-Smtp-Source: ABdhPJyFZM1C6Ro6ESujwMTx13Jm6ZfnrGCOz6gmBaSsjzqKubxAMd4JbOIBTy9B9rBi15NEjZYHfYaD2Ktn0PNs4w8= X-Received: by 2002:a05:6830:2f8:: with SMTP id r24mr12655469ote.375.1630968927373; Mon, 06 Sep 2021 15:55:27 -0700 (PDT) In-Reply-To: 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:213650 Archived-At: --0000000000008e4ca605cb5b8bdb Content-Type: text/plain; charset="UTF-8" > The global minor mode commands you bind could just > invoke a minibuffer key binding How? What I'm trying to do is avoid overriding a minibuffer key binding established by another package, which I don't control. > if you don't want the global minor mode to have > _any_ effect in the minibuffer No, generally the desired behavior for these use cases is that the keybinding will by default be active in the minibuffer, unless minibuffer-local-map happens to override that key, in which case minibuffer-local-map should be preferred. > is it only about key bindings That's the problem I face, yes. Per my above comment, just conditionally disabling the minor mode doesn't actually solve the problem. Unless you were to conditionally disable it by scanning minibuffer-local-map for a specific set of keybindings, which feels somewhat horrifying. More generally though, it would be really nice if there were a way to specify the numeric priority of a keybinding. Currently, minor modes are unconditionally preferred over major modes and minibuffer bindings, which are unconditionally preferred over global bindings. Usually this is what you want, but when it isn't, the workarounds feel pretty hacky. --0000000000008e4ca605cb5b8bdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The global minor mode commands you bind could just> invoke a minibuffer key binding
How? What I'm trying to d= o is avoid overriding a minibuffer key binding established by another packa= ge, which I don't control.

> if you don'= ;t want the global minor mode to have
> _any_ effect in the minibuf= fer

No, generally the desired behavior for these use cas= es is that the keybinding will by default be active in the minibuffer, unle= ss minibuffer-local-map happens to override that key, in which case minibuf= fer-local-map should be preferred.

> is it only= about key bindings

That's the problem I f= ace, yes. Per my above comment, just conditionally disabling the minor mode= doesn't actually solve the problem. Unless you were to conditionally d= isable it by scanning minibuffer-local-map for a specific set of keybinding= s, which feels somewhat horrifying.

More generally= though, it would be really nice if there were a way to specify the numeric= priority of a keybinding. Currently, minor modes are unconditionally prefe= rred over major modes and minibuffer bindings, which are unconditionally pr= eferred over global bindings. Usually this is what you want, but when it is= n't, the workarounds feel pretty hacky.

--0000000000008e4ca605cb5b8bdb--