From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Psionic K Newsgroups: gmane.emacs.devel Subject: Re: Delegating user-reserved key binding space definition to users Date: Sun, 27 Nov 2022 05:53:18 -0600 Message-ID: References: <57b69c22e167d429d21bb969feb22887@webmail.orcon.net.nz> <877czikyfa.fsf@localhost> <87o7sthrwx.fsf@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000046a72905ee7267d7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10526"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Ihor Radchenko , Stefan Monnier To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 27 12:54:07 2022 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 1ozGEY-0002Vs-GR for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Nov 2022 12:54:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozGEA-0001kC-CR; Sun, 27 Nov 2022 06:53:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ozGE2-0001jA-Ul for emacs-devel@gnu.org; Sun, 27 Nov 2022 06:53:37 -0500 Original-Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ozGE0-0004ov-55 for emacs-devel@gnu.org; Sun, 27 Nov 2022 06:53:34 -0500 Original-Received: by mail-pj1-x1029.google.com with SMTP id mv18so7125887pjb.0 for ; Sun, 27 Nov 2022 03:53:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/FqN4Do5ATbXEodqyH7pN/CrF/iPzhuxKkzFmPecjOw=; b=Tq3vu3CaFcZjg6Z6myQYQhvzQeusRJsAZJJIOYUafnaWewGOd9a8joT99vyi9QqXTr zR+Sf6Q1vl2tBpkqq4UW/ToFHRbwMsSoDOQr0HXSYA9aqAPOBXzEPwKHbbj+68nhXsmN H2WZNtgiUIpPqiVBqegGhbe5NNNJyIN8n4ur7h62zCv+s9/FUC445hlcbchj/rf/UrYA Zl1ypnBUg0QIPJLMCKFF//L06k0R2DD9f1licfzox2DrxZLsP/CnSpgADofu0QhBK2wc Q5ouDa2HSgUBZIaIF7ZQkZSvwzv9Vd6MyErzZoMbX6JVASPhPRQUywVrkP29qblK2dkO VpGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/FqN4Do5ATbXEodqyH7pN/CrF/iPzhuxKkzFmPecjOw=; b=U1NCu1mwFdg1hwLSiUFP3IKuYPpf9Qu+GCfT2JyHlVO/MG/HFqq6obuyoUsKtvqLAN f6KjClqKLauXOZ1P2K4WuQKmQT2CNrg4yc4pbJzo+sqCxwxB4qv+TXGM1++wd0YFv81w ZE4TiSYqCKWiXp+OOXgVCCzZ95tIMF1sXsiIDrtgZWl6BwZ1Az8s0pkmbAxSzF7JCmTj tOBjtHxv7Ii9F1W2JVZtrRPDgu/h7/QU3YHnKopEmMQfXH4l41/OswiO4mZi/uaaNKgR SPJp40Vg5hvi0+FAEli6wBEGCevn5mKSUPVXQYI+OUOQUucNpW3ooAKQY+OW4o4WMyT+ 6erA== X-Gm-Message-State: ANoB5pnkpDO54J+7q7n7dzU5+ZLOIKleWpN+pkxuPBzcbhFDWmfB7+h5 2MFfmeOMfyurtZCktP/s0UjPuRGZv3U2lkP2MqscT/GWVPXGNg== X-Google-Smtp-Source: AA0mqf4FzltvETO6yw66QYtaMnGkDNWmtXtm/hYRUQhYF/HXN4CkaU2SwOVYX/NDVPP65ByuwXdv83w7H937PP58gtE= X-Received: by 2002:a17:902:aa06:b0:183:7f67:25d7 with SMTP id be6-20020a170902aa0600b001837f6725d7mr27370063plb.164.1669550009912; Sun, 27 Nov 2022 03:53:29 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::1029; envelope-from=exec@positron.solutions; helo=mail-pj1-x1029.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, HTML_MESSAGE=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.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300625 Archived-At: --00000000000046a72905ee7267d7 Content-Type: text/plain; charset="UTF-8" At this point, I'm thinking about supporting continuity and adoption. Some users will want to change and some will want to stay the same. The short answer is not to define any abstract commands or forbidden / reserved sequences if you want the current behavior. We can start by only defaulting abstract commands that are effectively in consensus already. After adding the obvious abstract commands, there's not many bindings that map to consistent concepts I can think of. However, this is not the problem it seems like. While a major mode author may wish to create more bindings, they are not entitled to any of the user's keyspace. It will suffice for mode writers to know which key sequences are: - designated for a purpose in other modes - designated for use by the user - never to be mapped under any circumstances At the time of map generation, if a mode finishes mapping designated abstract keys, they must choose keys that don't match the other two groups. These bindings may all be suboptimal or too few to implement the mode writer's wishes, but this is the user's choice. A user-overridable sequence successor function could add bindings to a set of valid sequences. If a mode needs more than just a single prefix key, this should suffice, and the user can define that function to nil to block all extraneous bindings. Mode authors should focus on introducing their commands through README's, good docstrings for completions, and good command names. Bindings are not a good index of discovery for commands. If a mode has a well implemented data model and set of functions for building commands, this is much more useful than having a bunch of maybe useful commands bound. On Sun, Nov 27, 2022 at 5:26 AM Psionic K wrote: > I tested remap shadowing just now, and it works in 28.2. A higher > precedence remap will shadow a lower precedence remap. This means the user > can bind a sequence to an abstract command, give it a remap in the global > map, and have a different remap in a mode map. When the user rebinds the > abstract command, everything goes with it. > > > I suggest introducing a notion of "generalized" commands. Such commands > will represent common actions executed by users (like move to > next/previous element). Major and minor modes can then define specific > implementation of the actions. > > We can do this with shadowing in higher precedence maps. As above, this > works for command remapping, but the issue is that we need a solid place to > remap to, not a command that the user might replace. If the user defines a > command like "next-line-unfold" in the the global map, a mode generating a > map by looking for "next-line" would not find the correct target. > > This is the situation today, with ad-hoc imitation of the default global > map. Modes map to sequences without knowing what the user wants those > sequences to be. We basically need a convention to name the keys through > abstract commands instead of using sequences, which really are zero > indication of what the user wants that key to do. Binding sequences to > abstract commands completely solves this. > > >You cannot achieve this by simple remapping, AFAIK. > > Each major mode map would shadow the global map's shadow of the > "user-right" abstract command. Instead of the abstract command sequence > remapping to the global concrete command, the major mode's concrete command > remap would take precedence. Totally works. > > > On Sat, Nov 26, 2022 at 11:44 PM Ihor Radchenko > wrote: > >> Stefan Monnier writes: >> >> >> I suggest introducing a notion of "generalized" commands. Such commands >> >> will represent common actions executed by users (like move to >> >> next/previous element). Major and minor modes can then define specific >> >> implementation of the actions. >> > >> > I think it's a non-starter because it requires foresight: only those >> > commands defined with this mechanism will be extensible. I agree that >> > an additional level of indirection is probably necessary, but I suspect >> > it needs to be placed elsewhere. >> >> Auto-remapping will need some kind of grouping for commands one way or >> another. There is no way we can do it auto-magically. Developer or users >> should decide. >> >> Currently, the commands in major mods are bound to specific key >> bindings. The bindings are chosen either arbitrarily, according to major >> mode author preferences, or according to semi-established default key >> binding scheme (like C-f/C-M-f/C-n/C-v/etc). Either way, trying to >> re-bind commands in multiple major modes is not easy. >> >> Note that a number of commands like `comment-forward' already expect >> major modes to fit into an established, pre-defined framework by >> tweaking the `comment-forward' customization according to the major >> mode. This also requires a foresight. >> >> My suggestion is somewhat similar to the existing practices of major >> mode writing where the author is required to configure comment handling, >> paragraph handling, sentence rules, imenu, etc. >> >> However, what I suggest is more flexible as it does not require Emacs >> core developers to provide extensive configuration mechanism for, say, >> `next-line' individually; `previous-line' individually, ... >> Instead, it will be sufficient to declare generalized command and then >> rely on major modes to hook in. Users should be able to do it easily >> too. >> >> > [ FWIW, you can get similar results with the current setup using >> > command remapping. ] >> >> You are absolutely right: when a major mode command is related to >> built-in command in command map. >> >> However, some major modes introduce new concepts. For example, think >> about paredit-forward-slurp-sexp, which can be an equivalent of Org's >> heading promotion or moving word at point forward in sentences. How >> could you remap to group these 3 very different yet similar (for some >> users) commands together? >> >> I imagine that users can define a generalized command "move right" >> themselves, give it a default binding in overriding global map, and then >> make `paredit-forward-slurp-sexp', `org-promote', and `transpose-words' >> be selected when running "move right" depending on the active major >> mode. You cannot achieve this by simple remapping, AFAIK. >> >> -- >> Ihor Radchenko // yantar92, >> Org mode contributor, >> Learn more about Org mode at . >> Support Org development at , >> or support my work at >> > > > -- > > Psionic K > Software Engineer > > *Positron Solutions * > -- Psionic K Software Engineer *Positron Solutions * --00000000000046a72905ee7267d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At this point, I'm thinking about supporting cont= inuity and adoption.=C2=A0 Some users will want to change and some will wan= t to stay the same.

The short answer is not to define any= abstract commands or forbidden / reserved sequences if you want the curren= t behavior.=C2=A0 We can start by only defaulting abstract commands that ar= e effectively in consensus already.

After addi= ng the obvious abstract commands, there's not many bindings that map to= consistent concepts I can think of. However, this is not the problem it se= ems like.=C2=A0 While a major mode author may wish to create more bindings,= they are not entitled to any of the user's keyspace.

It will suffice for mode writers to know which key sequences are:
  • designated for a purpose in other modes
  • designated for us= e by the user
  • never to be mapped under any circumstances
    • At the time of map generation, if a mode finishes mapping des= ignated abstract keys, they must choose keys that don't match the other= two groups.=C2=A0 These bindings may all be suboptimal or too few to imple= ment the mode writer's wishes, but this is the user's choice.=C2=A0= A user-overridable sequence successor function could add bindings to a set= of valid sequences.=C2=A0 If a mode needs more than just a single prefix k= ey, this should suffice, and the user can define that function to nil to bl= ock all extraneous bindings.

    Mode authors should focus on= introducing their commands through README's, good docstrings for compl= etions, and good command names.=C2=A0 Bindings are not a good index of disc= overy for commands.=C2=A0 If a mode has a well implemented data model and s= et of functions for building commands, this is much more useful than having= a bunch of maybe useful commands bound.

    On Sun, Nov 27, 2022 at 5= :26 AM Psionic K <psionik@positron.solutions> wrote:
    I tested r= emap shadowing just now, and it works in 28.2.=C2=A0 A higher precedence re= map will shadow a lower precedence remap.=C2=A0 This means the user can bin= d a sequence to an abstract command, give it a remap in the global map, and= have a different remap in a mode map.=C2=A0 When the user rebinds the abst= ract command, everything goes with it.

    > I suggest introducing a notion of "generalized" commands. Such co= mmands
    will represent common actions executed by users (like move to
    next/previous element). Major and minor modes can then define specific
    implementation of the actions.

    We can do= this with shadowing in higher precedence maps.=C2=A0 As above, this works = for command remapping, but the issue is that we need a solid place to remap= to, not a command that the user might replace.=C2=A0 If the user defines a= command like "next-line-unfold" in the the global map, a mode ge= nerating a map by looking for "next-line" would not find the corr= ect target.

    This is the situation today, with = ad-hoc imitation of the default global map.=C2=A0 Modes map to sequences wi= thout knowing what the user wants those sequences to be.=C2=A0 We basically= need a convention to name the keys through abstract commands instead of us= ing sequences, which really are zero indication of what the user wants that= key to do.=C2=A0 Binding sequences to abstract commands completely solves = this.

    >You cannot achieve this by simple remapp= ing, AFAIK.

    Each major mode map would shadow the global m= ap's shadow of the "user-right" abstract command.=C2=A0 Inste= ad of the abstract command sequence remapping to the global concrete comman= d, the major mode's concrete command remap would take precedence.=C2=A0= Totally works.


    On Sat, Nov 26, 2022 at= 11:44 PM Ihor Radchenko <yantar92@posteo.net> wrote:
    Stefan Monnier <monnier@iro.umontreal.ca> wri= tes:

    >> I suggest introducing a notion of "generalized" commands= . Such commands
    >> will represent common actions executed by users (like move to
    >> next/previous element). Major and minor modes can then define spec= ific
    >> implementation of the actions.
    >
    > I think it's a non-starter because it requires foresight: only tho= se
    > commands defined with this mechanism will be extensible.=C2=A0 I agree= that
    > an additional level of indirection is probably necessary, but I suspec= t
    > it needs to be placed elsewhere.

    Auto-remapping will need some kind of grouping for commands one way or
    another. There is no way we can do it auto-magically. Developer or users should decide.

    Currently, the commands in major mods are bound to specific key
    bindings. The bindings are chosen either arbitrarily, according to major mode author preferences, or according to semi-established default key
    binding scheme (like C-f/C-M-f/C-n/C-v/etc). Either way, trying to
    re-bind commands in multiple major modes is not easy.

    Note that a number of commands like `comment-forward' already expect major modes to fit into an established, pre-defined framework by
    tweaking the `comment-forward' customization according to the major
    mode. This also requires a foresight.

    My suggestion is somewhat similar to the existing practices of major
    mode writing where the author is required to configure comment handling, paragraph handling, sentence rules, imenu, etc.

    However, what I suggest is more flexible as it does not require Emacs
    core developers to provide extensive configuration mechanism for, say,
    `next-line' individually; `previous-line' individually, ...
    Instead, it will be sufficient to declare generalized command and then
    rely on major modes to hook in. Users should be able to do it easily
    too.

    > [ FWIW, you can get similar results with the current setup using
    >=C2=A0 =C2=A0command remapping.=C2=A0 ]

    You are absolutely right: when a major mode command is related to
    built-in command in command map.

    However, some major modes introduce new concepts. For example, think
    about paredit-forward-slurp-sexp, which can be an equivalent of Org's heading promotion or moving word at point forward in sentences. How
    could you remap to group these 3 very different yet similar (for some
    users) commands together?

    I imagine that users can define a generalized command "move right"= ;
    themselves, give it a default binding in overriding global map, and then make `paredit-forward-slurp-sexp', `org-promote', and `transpose-wo= rds'
    be selected when running "move right" depending on the active maj= or
    mode. You cannot achieve this by simple remapping, AFAIK.

    --
    Ihor Radchenko // yantar92,
    Org mode contributor,
    Learn more about Org mode at <https://orgmode.org/>.
    Support Org development at <https://liberapay.com/org-mode>,=
    or support my work at <https://liberapay.com/yantar92>


    --
    =


    --

    Software Engineer
    <= /div>
    --00000000000046a72905ee7267d7--