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: Delegating user-reserved key binding space definition to users Date: Mon, 21 Nov 2022 08:40:58 -0600 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d5c67c05edfc0b97" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23393"; mail-complaints-to="usenet@ciao.gmane.io" To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 21 15:42:24 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 1ox807-0005qG-UQ for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Nov 2022 15:42:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ox7z5-0001Bc-9h; Mon, 21 Nov 2022 09:41:19 -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 1ox7z0-00018q-2Z for emacs-devel@gnu.org; Mon, 21 Nov 2022 09:41:15 -0500 Original-Received: from mail-pf1-x431.google.com ([2607:f8b0:4864:20::431]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ox7yx-0005Kj-UE for emacs-devel@gnu.org; Mon, 21 Nov 2022 09:41:13 -0500 Original-Received: by mail-pf1-x431.google.com with SMTP id 140so11507943pfz.6 for ; Mon, 21 Nov 2022 06:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=mTJHiNDmRH8vSgoexPs8p2IdmeswiZzEa4osYPlGMJw=; b=DKauzrJ8kPKJHtqkajEGbHPWKoGwxqg6AGlG9ii4iGm6CqFSSm4awfreY1W1rYWDU4 tn0XZRAinkXUCCnUeN1pBvaSfqJt5azQ6QcyMXnLLTvxarz4mdSwtioUMKCtOrVUZwkU 4gQwkyBJRqyKywbG8/cMeLYJrZTLzmWig9z9hu19yiMFv5UEQUfhwrOc9P4nWAIfZh1x XwPz7dxLIA6K3mUQILCgI0j8FEiO9TzCigO895W27/0sZcbggn1dFumktEY4FAeThIpX MUut3Cez0UYeUg+9yzG5Gro3U6sdlP4CuAz4gAVwF5qxuo+2ykfETziNK5tWFVy7KPYC tzvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=mTJHiNDmRH8vSgoexPs8p2IdmeswiZzEa4osYPlGMJw=; b=M4jQreu/RoC7ljb3ipzTXm+mGSTWoPSNYuzc6jW4qnrthX0a0SXFuIuTnSI9GLnimi sgjaA9qI7nCVU1ZaBrffxFbmz3WQiDhFVu3ceQ0FUIRm8Q7MaYGaq1IiRboR07UmiPnp Z/yx5okQ46edLtKNfD6KZKt+wOkbimFUa6jMSa0dfVmFtDXquRcHhBqDkcud63P28T85 P/YQpIbTwmFj+VvniCwKvuI60ROE9W8w1RqoInIR3zhLu69ab64PYyjloHI2Ua+KWqiy Mnzax1vP09vCpI2tIdwZGDTyvkRKhdinMYaaiIzNxJ2mPht8p41lP6SznpijAcsiLSi5 AjDA== X-Gm-Message-State: ANoB5pmnBI4rNDLIIgIGy9icDyBGQmnU9z4xSTgBMUuYDKdwVarfGaki EZq2P1veUiwo56re91vcHKs7lp4AvqW91QM4aEBw2RGw6c1hug== X-Google-Smtp-Source: AA0mqf4h9jKtTyPPXNJhGk2MsPLWnyuQUexTww88diGoXRZgt1zVX8XNSmUi8fM8rCbCSNZWkrin5ds9StS7ShlVxTc= X-Received: by 2002:aa7:86c9:0:b0:565:c122:b63 with SMTP id h9-20020aa786c9000000b00565c1220b63mr785851pfo.49.1669041669646; Mon, 21 Nov 2022 06:41:09 -0800 (PST) Received-SPF: pass client-ip=2607:f8b0:4864:20::431; envelope-from=exec@positron.solutions; helo=mail-pf1-x431.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:300300 Archived-At: --000000000000d5c67c05edfc0b97 Content-Type: text/plain; charset="UTF-8" The purpose of this email is to identify if a package should be created or if the technical implementation requires modification to Emacs. The motivating problem was to eliminate the possibility of Emacs defaults or packages creating many bindings sequences in two primary categories: - Multiple modifiers such as M-S-* or long sequences such as C-* C-* *. M-? is also an example of what I consider to require multiple-modifiers on a US key layout where '?' requires shift. - High-value space such as M-* and C-* In order to enforce this choice, the user needs control over the effects of all calls to create bindings, from an early phase and then persistently through startup and future package loading. The user needs a way to express, in the same dimensions as the implementation, which keys should receive no-op bindings if not explicitly created by the user. A complementary set of functions should allow the user to then make bindings into the protected keyspace, free from any potential interference. I was asked to relay my opinion that Emacs should ship with bindings not much more densely populated than nano. Nano does not have commands, so Emacs needs M-x, for example. It was suggested that advice might work for implementation, up to a point, since define-key doesn't have a dedicated code of some type I'm unaware of. The suggestion was made to live with emulation mode maps or even terminal overriding maps. I have two concerns about this technically. Such a solution provides no consultative feedback, a blind solution. Second, it doesn't help users who are already leaning on such maps for modal editing. My personal preference is to find a path to a mostly complete implementation as an independent package in order to figure out the problem better, gaining the breadth of information necessary through incremental adoption. I am intending to explore a simple advice of define-key. My implementation will no-op any request to bind a command to a key sequence that doesn't pass a predicate list. Optionally a report will be stored about which command bindings were no-op'd and by which filter predicate. Support for command and key translation inside of predicates would be my next feature. If there are multiple key mechanisms I need to intercept, an enumeration of them will be greatly appreciated. -- Psionic K Software Engineer *Positron Solutions * --000000000000d5c67c05edfc0b97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The purpose of this email is to identify if a package= should be created or if the technical implementation requires modification= to Emacs.

The motivating problem was to eliminate the po= ssibility of Emacs defaults or packages creating many bindings sequences in= two primary categories:
  • Multiple modifiers such as M-S-*= or long sequences such as C-* C-* *.=C2=A0 M-? is also an example of what = I consider to require multiple-modifiers on a US key layout where '?= 9; requires shift.
  • High-value space such as M-* and C-*
    • In order to enforce this choice, the user needs control over the eff= ects of all calls to create bindings, from an early phase and then persiste= ntly through startup and future package loading.=C2=A0 The user needs a way= to express, in the same dimensions as the implementation, which keys shoul= d receive no-op bindings if not explicitly created by the user.=C2=A0 A com= plementary set of functions should allow the user to then make bindings int= o the protected keyspace, free from any potential interference.

    I wa= s asked to relay my opinion that Emacs should ship with bindings not much more densely populated than nano.=C2=A0 Nano does not have commands, = so Emacs needs M-x, for example.

    It was suggested th= at advice might work for implementation, up to a point, since define-key do= esn't have a dedicated code of some type I'm unaware of.

    The suggestion was made to live with emulation mode maps or even te= rminal overriding maps.=C2=A0 I have two concerns about this technically.= =C2=A0 Such a solution provides no consultative feedback, a blind solution.= =C2=A0 Second, it doesn't help users who are already leaning on such ma= ps for modal editing.

    My personal preference is to find= a path to a mostly complete implementation as an independent package in or= der to figure out the problem better, gaining the breadth of information ne= cessary through incremental adoption.

    I am intending to e= xplore a simple advice of define-key.=C2=A0 My implementation will no-op an= y request to bind a command to a key sequence that doesn't pass a predi= cate list.=C2=A0 Optionally a report will be stored about which command bin= dings were no-op'd and by which filter predicate.=C2=A0 Support for com= mand and key translation inside of predicates would be my next feature.

    If there are multiple key mechanisms I need to interc= ept, an enumeration of them will be greatly appreciated.

    --
    <= /div>
--000000000000d5c67c05edfc0b97--