From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 8K+tNLYsXWeaygAAe85BDQ:P1 (envelope-from ) for ; Sat, 14 Dec 2024 06:59:03 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 8K+tNLYsXWeaygAAe85BDQ (envelope-from ) for ; Sat, 14 Dec 2024 07:59:03 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=positron.solutions header.s=google header.b=GiAPDE+N; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1734159542; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=4ZlMagU9G3uXT+FylFrRSIpJtNyTqvLa4N0y9IaK6fE=; b=QP4P8evFdXjgBCG+84HPjPM2CQgeonadCb2DFnfBRJnvg0BhCsyxO0tRn8UFs/eHvXw8Eq C8TwwQnLvcdhe8B0epEG7pAhFwNUM7uFVLCjF7UDkfTFhg1TfvK67pvpYswZpO+IDvJzb+ R3F0WlAQsLW6EEeT+haQjfvYL7izBu31iyLAneO8qg/wZvnevyfjw3bx8a0gPPn7o/uufH K9R91duOBoigRkfHzYf7cpRPozD9YOP7pc60xk7sYXVIfcmmguhGXzSZgYttkNMw30qDQB oktzzyrZYOsu4cVKsIQXk2w/xHgO5j/tP/Ctd6rTLGrcQX40vilQ7p2ZrfQgeA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=positron.solutions header.s=google header.b=GiAPDE+N; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1734159542; a=rsa-sha256; cv=none; b=VMJdUierFEiwKri801FMbMPiAkNZDUXjBrEou6toMozr/D1c2pJ3gP3+lFuxCpxPGPD93O MYSbaONo+mGdHKhp3k5hPL4VGYbd/4UvMQnzTlZwxq1C4PCWnI1Vqfh+Bn+ErT2uE/UnPA lpH+9R0oNDnicbyyygRADFdRGaMb1kmEROGcoCc5pXpGFCrgyV9krzmfg5cORusbus0DTR 3uyarGoDzM9INYd2L8cC6Iyd0zT606kQciJ9llTGOYXl9yPVeBLjrSKvGNZnPNbcWd+63L mYVkeSa8jpMi9ozvG4K8yK8nYxiopzsdq/MxWZire9GuO5qp+gTClJAGnyJoTg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id F3C7B83E15 for ; Sat, 14 Dec 2024 07:59:01 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMM6P-0007bd-FZ; Sat, 14 Dec 2024 01:58:13 -0500 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 1tMGAK-0003CT-3n for emacs-orgmode@gnu.org; Fri, 13 Dec 2024 19:37:52 -0500 Received: from mail-yw1-x1135.google.com ([2607:f8b0:4864:20::1135]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tMGAG-0005OU-MV for emacs-orgmode@gnu.org; Fri, 13 Dec 2024 19:37:51 -0500 Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-6f27c47b4e6so9065747b3.0 for ; Fri, 13 Dec 2024 16:37:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=positron.solutions; s=google; t=1734136664; x=1734741464; darn=gnu.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=4ZlMagU9G3uXT+FylFrRSIpJtNyTqvLa4N0y9IaK6fE=; b=GiAPDE+NbtK0kL6+U++qkkT6nbo24nrjkv0HkVC2VvzM9OiPV3qW4vA0OKkl5RmNRJ DrSyiYv2nzu1hK4+0e6TPPap4WbQO0BB/zqp+KIULESZBSMGmZE18YfF1t50Xae/vmSW VIOptFP0YjGGBW2ETRwIQNwrKw+p+KiJDy5fDaRbZ/UzKEMaBOFjJyQD7JmTCcRwv/14 1LrGfqQvvWyJRwETe/QppzVPkFLg4gVS4qHydWfQla8/07oKXPEZTS/uex/JCbT0h2HU VR20YaENzY621Y7Xm2qgxvPZXr8aDqu7DSpAgWzChcfIeOsHpoyeaOCv1WlzcSnq76Ky e/pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734136664; x=1734741464; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=4ZlMagU9G3uXT+FylFrRSIpJtNyTqvLa4N0y9IaK6fE=; b=ovkwZDMG1pSt/NZL85B7Bc5FOWeyd6N+449seN/FPQEar3dOghmc+d9WrVJD1uD/Lf b4mvME1p/0/Tla+aawmpdh6nHAAyXrqG0Bp7+Pmdfd5VqCIklZG/NKF8JwYrFmsYKDNk R9IUD9O2r6JhEdw1fNT4IBNCFGUn9VBu2Ug6jXvbYtpAe5GTMhF+A++e+swwOrIbQOgj eHSjHSQ/s0xF6YTcXcZr2+Cvf4D/GsiGfotkKQmgt7C9IzBhzKLYbJo2mQbcljp4gQnf 5tSEUv9dGx7eHZCPTNWt+u9P0MaGeIgzUE4+J6ETjy0GkoZNeMgTS4j9B7X1vDsHl+mw ZuCA== X-Forwarded-Encrypted: i=1; AJvYcCXELmAvwKxwWfSYZqaaJjgFryvZtRoesrZdSfi1UbmkjHnUkfQaBv2xcMhYIYvPQYHJeVtdo+pz9aXmSqfx@gnu.org X-Gm-Message-State: AOJu0YyPFBuzdcFk8zrnKrfEAzF+a4DvtUAB4w96mxYu+NKj+ZMV8BYa 20cvOfzzusD5bs4+SB2wNy57BUsojT/dk8ZcgwCgQoRGHaa0oOPT+RrAnEYfRtvwpViSvucuLjH Vh92I3N2mV+UwAwsZfeu8pPYvBMAYGJUhfvYr6Q== X-Gm-Gg: ASbGncuS5bd2dKkOEZ5jIsu3jdnoIS+pL0gb10Wo3PLnrtfcuw2BRC+O6BFo1VtAHT8 AIOJMUvzAllKT7iFJH3A7tVal58OUP2i3XXyiydrr X-Google-Smtp-Source: AGHT+IFwCBIyIkuQwP7RGbMf+Iuajq833JrS21rmVfXFDsQnQeK9hLBmDUBWLsy1FDodO8HQKvrHvk90w88byI7J+E8= X-Received: by 2002:a05:690c:4510:b0:6ef:5848:2a82 with SMTP id 00721157ae682-6f279b3fa2cmr42888997b3.25.1734136664375; Fri, 13 Dec 2024 16:37:44 -0800 (PST) MIME-Version: 1.0 From: Psionic K Date: Sat, 14 Dec 2024 09:37:33 +0900 Message-ID: Subject: Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?) To: Ihor Radchenko Cc: charles.choi@yummymelon.com, Emacs developers , emacs-orgmode@gnu.org, emacs.transient@jonas.bernoulli.dev, juri@linkov.net, justin@burkett.cc, karthikchikmagalur@gmail.com, omar@matem.unam.mx, Philip Kaludercic , tclaesson@gmail.com, visuweshm@gmail.com Content-Type: multipart/alternative; boundary="000000000000df67360629302746" Received-SPF: pass client-ip=2607:f8b0:4864:20::1135; envelope-from=exec@positron.solutions; helo=mail-yw1-x1135.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-Mailman-Approved-At: Sat, 14 Dec 2024 01:58:06 -0500 X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: -3.74 X-Spam-Score: -3.74 X-Migadu-Queue-Id: F3C7B83E15 X-TUID: enxdSe+xwUoX --000000000000df67360629302746 Content-Type: text/plain; charset="UTF-8" > intercepts the main loop This is optional, per transient menu (prefix) and the commands within it. A common technique, used by magit and others, is to have entry point commands in the regular keymap so that many commands can be started without traversing several menus. If you want normal un-shadowed bindings active at the same time, the prefix has a slot called `transient-non-suffix' that is similar to the `:suppress' option in keymaps or setting a `t' `undefined' binding in a keymap. However the results of mixing self-insert and modal or modal and another modal are generally bad. The biggest drawbacks of transient are well known in Github issues: - Which-key discovery of Transient keymaps - Transient binding generation based on keymaps - Normalizing how to obtain arguments when being called independently as an interactive command versus being called as a Transient suffix In the short term, to punch the first two problems in the face, override the `:setup-children' method. If you know what keymap you are borrowing bindings from, you can synchronize it at display time. Regarding the normalization with interactive, if you are not using transient infixes and instead lean on the :info class and dynamic :descriptions, you can display state and store it using normal buffer-local and defvar techniques, providing visual feedback for what might be hidden states after the user gets more familiar. The commands work with or without a prefix currently active. In this usage model, you only use Transient for its flow control, display, and layout. I find the infix system to be somewhat of a distraction if you are not actually building a CLI wrapper, but you can definitely make suffixes and descriptions "smart" by reading a scope from the prefix and making custom infixes that also obtain more state when displayed. A custom infix for storing org elements or objects could certainly be a thing. I think deeper user customization is an area that is weak with transient, but only because the user actually needs to have a vision for how they want to build up stateful commands. If you're just doing prefix maps, transient and hydra are equivalent concepts. Transient becomes differentiated when you consider commands that build up state for other commands. Executing slightly modified command sentences in rapid succession is not something the user customizes casually. Complex commands only make sense when the context they depend on is populated, which naturally decides the menu flow. > I am wondering if we can work out some universal API to plug the > described action->menu->selection model into the UI that user prefers. > > Tentatively, I am thinking about the following: > > For a given Emacs "prefix" command (e.g. org-open-at-point), we define a > set of customizations: > > 1. List of possible actions: ((name1 . action1 props) (name2 . action2 ...) ...) > PROPS is a plist defining extra properties like key-binding, display > string, maybe something else to be used in the future. > 2. Menu interface to use (transient, context-menu, embark, which-key) > 3. Layout settings for the specific interfaces. For example, transient > layout definition. Well, I'm sure you know that transient has more decisions encoded in the layout than the other options. If the data going in is a least common denominator, you need supplementary data elsewhere to achieve a good result. What I fear is a system like org-speed-keys which relies on an override of `org-self-insert' and is yet another orthogonal system. I much prefer the Lispy style of integration, which uses a keymap. Using keymaps, even if they are not active, to generate transient key bindings via :setup-children is the best way to have certain integration with other Emacs tools. How people can collaborate with me on general questions of design is to open issues on the Transient Showcase. Either I can point to an existing example or make a new one. I've been giving some thought to how to demonstrate an idea more generally of composing multiple commands and manipulating the composition to dispatch complex commands in rapid succession with minor differences. I personally have my own org speed keys solution that I've been developing for yet another more complex package I call Afterburner. These projects can become stuck in design hell when I don't have the prodding from other problem analysis, so please, bother me. https://github.com/positron-solutions/transient-showcase --000000000000df67360629302746 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> intercepts the main loop
This is optional, per tra= nsient menu (prefix) and the commands within it.=C2=A0 A common technique, = used by magit and others, is to have entry point commands in the regular ke= ymap so that many commands can be started without traversing several menus.= =C2=A0 If you want normal un-shadowed bindings active at the same time, the= prefix has a slot called `transient-non-suffix' that is similar to the= `:suppress' option in keymaps or setting a `t' `undefined' bin= ding in a keymap.=C2=A0 However the results of mixing self-insert and modal= or modal and another modal are generally bad.

The biggest drawbacks= of transient are well known in Github issues:
- Which-key discovery of = Transient keymaps
- Transient binding generation based on keymaps
- N= ormalizing how to obtain arguments when being called independently as an in= teractive command versus being called as a Transient suffix

In the s= hort term, to punch the first two problems in the face, override the `:setu= p-children' method.=C2=A0 If you know what keymap you are borrowing bin= dings from, you can synchronize it at display time.=C2=A0

Rega= rding the normalization with interactive, if you are not using transient in= fixes and instead lean on the :info class and dynamic :descriptions, you ca= n display state and store it using normal buffer-local and defvar technique= s, providing visual feedback for what might be hidden states after the user= gets more familiar.=C2=A0 The commands work with or without a prefix curre= ntly active.=C2=A0 In this usage model, you only use Transient for its flow= control, display, and layout.=C2=A0 I find the infix system to be somewhat= of a distraction if you are not actually building a CLI wrapper, but you c= an definitely make suffixes and descriptions "smart" by reading a= scope from the prefix and making custom infixes that also obtain more stat= e when displayed.=C2=A0 A custom infix for storing org elements or objects = could certainly be a thing.

I think deeper user customization is an = area that is weak with transient, but only because the user actually needs = to have a vision for how they want to build up stateful commands.=C2=A0 If = you're just doing prefix maps, transient and hydra are equivalent conce= pts.=C2=A0 Transient becomes differentiated when you consider commands that= build up state for other commands.=C2=A0 Executing slightly modified comma= nd sentences in rapid succession is not something the user customizes casua= lly.=C2=A0 Complex commands only make sense when the context they depend on= is populated, which naturally decides the menu flow.

> I a= m wondering if we can work out some universal API to plug the
> descr= ibed action->menu->selection model into the UI that user prefers.
= >
> Tentatively, I am thinking about the following:
>
>= ; For a given Emacs "prefix" command (e.g. org-open-at-point), we= define a
> set of customizations:
>
> 1. List of possibl= e actions: ((name1 . action1 props) (name2 . action2 ...) ...)
> =C2= =A0 =C2=A0PROPS is a plist defining extra properties like key-binding, disp= lay
> =C2=A0 =C2=A0string, maybe something else to be used in the fut= ure.
> 2. Menu interface to use (transient, context-menu, embark, whi= ch-key)
> 3. Layout settings for the specific interfaces. For example= , transient
> =C2=A0 =C2=A0layout definition.

Well, I'm su= re you know that transient has more decisions encoded in the layout than th= e other options.=C2=A0 If the data going in is a least common denominator, = you need supplementary data elsewhere to achieve a good result.

What= I fear is a system like org-speed-keys which relies on an override of `org= -self-insert' and is yet another orthogonal system.=C2=A0 I much prefer= the Lispy style of integration, which uses a keymap.=C2=A0 Using keymaps, = even if they are not active, to generate transient key bindings via :setup-= children is the best way to have certain integration with other Emacs tools= .

How people can collaborate with me on general questions of design = is to open issues on the Transient Showcase.=C2=A0 Either I can point to an= existing example or make a new one.=C2=A0 I've been giving some though= t to how to demonstrate an idea more generally of composing multiple comman= ds and manipulating the composition to dispatch complex commands in rapid s= uccession with minor differences.=C2=A0 I personally have my own org speed = keys solution that I've been developing for yet another more complex pa= ckage I call Afterburner.=C2=A0 These projects can become stuck in design h= ell when I don't have the prodding from other problem analysis, so plea= se, bother me.

https://github.com/positron-solutions/transient-showcase
--000000000000df67360629302746--