* Re: Org-cite: Replace basic follow-processor with transient menu? [not found] ` <87a5ewfvo1.fsf@gmail.com> @ 2024-10-22 17:58 ` Ihor Radchenko 0 siblings, 0 replies; 14+ messages in thread From: Ihor Radchenko @ 2024-10-22 17:58 UTC (permalink / raw) To: Tor-björn Claesson; +Cc: emacs-orgmode, Jonas Bernoulli, emacs-devel [ CCing emacs-devel and the author of transient; maybe we can have some more suggestions this way ] For some context, we are trying to create a customizeable transient menu with items configured via user option. We are also trying to pass additional arguments from prefix to suffix commands in a way that there is no need to write suffix commands specially just for transient. Tor-björn Claesson <tclaesson@gmail.com> writes: > Ihor Radchenko <yantar92@posteo.net> writes: >> Thanks! This looks much more clean. >> Even better would be having a defcustom that defines the transient >> layout. The idea is to avoid hard-coding [["Open" ... ] ["Copy" ...] >> ...] and instead make it defcustom. > > Here is a solution that works for me. Is this an OK use of eval, or is > there a better way of doing this? > > (defcustom org-cite-basic-follow-actions > '[["Open" > ("b" "bibliography entry" org-cite-basic-follow.open-bibliography)] > ["Copy" > ("d" "DOI" org-cite-basic-follow.copy-doi)] > ["Browse" > ("u" "url" org-cite-basic-follow.browse-url)]] > "Contents of the org-cite-basic-follow transient menu. > > This can be customized directly using the customization > interface. Use setopt instead of setq if you change this option > in elisp, to ensure that the transient is rebuilt. +1 > Further actions can be added using transient-define-suffix." > :group 'org-cite > :type 'sexp > :set (lambda (option-name new-value) > (eval > `(transient-define-prefix org-cite-basic-follow (citation &optional prefix) > "Follow a citation reference. > > The contents of this transient menu is set in org-cite-basic-follow-actions." > ,new-value > (interactive) > (if (or org-cite-basic-follow-ask prefix) > (transient-setup 'org-cite-basic-follow nil nil :scope (list citation prefix)) > (org-cite-basic-goto citation prefix)))) > (set-default-toplevel-value option-name new-value))) This should work, but maybe Jonas can provide better ideas. >>> And I can then for example add my own pdf-action like this: >>> >>> (transient-append-suffix 'org-cite-basic-follow "b" >>> '("p" "pdf" >>> (lambda (citation prefix) >>> (interactive (oref (transient-prefix-object) scope)) >>> (find-file-other-window >>> (concat >>> tbc/projektet >>> "Referensartiklar" >>> "/" >>> (org-element-property :key citation) >>> ".pdf"))))) >> >> It feels a bit too complex to demand knowledge of these transient >> details (how to get the arglist) from users. >> >> I am wondering if we can somehow plug the existing commands passing the >> arguments without any extra setup on the user side. > > The lambda form is much neater with your (transient-scope) suggestion: > (lambda (citation prefix) > (interactive (transient-scope)) > ...) > > Is this simple enough? I don't feel a macro would improve the > situation. It is not too bad, but what I really wanted is to reuse an existing command/function without having to write a tailored interactive statement. Again, I am hoping to get some insight from emacs-devel. -- 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <87wmhlmp83.fsf@gmail.com>]
[parent not found: <871pzte929.fsf@localhost>]
[parent not found: <87v7x548ri.fsf@gmail.com>]
[parent not found: <87y120daue.fsf@localhost>]
[parent not found: <874j4m9ep6.fsf@gmail.com>]
[parent not found: <87h68gfqj1.fsf@localhost>]
[parent not found: <CAO0k701CGFnQwCCuODjTFuf=OTsj9Vdqg+COP8nkpJg0wL_hQg@mail.gmail.com>]
[parent not found: <87pln3f3cc.fsf@localhost>]
[parent not found: <CAO0k7006goK-AfhG+3PVwhz=4QU_DMm+5edmATZpjdRHkj61Bg@mail.gmail.com>]
[parent not found: <87jzd9ojj0.fsf@localhost>]
[parent not found: <87cyj0ajm9.fsf@gmail.com>]
[parent not found: <87zfm4s50x.fsf@localhost>]
[parent not found: <CAO0k703a5SCv4Eaogjs-14zgmTi-pK5qqG=8VzB8+7h-kcC8yg@mail.gmail.com>]
[parent not found: <87wmh8s358.fsf@localhost>]
[parent not found: <87y11nwp9z.fsf@gmail.com>]
[parent not found: <CAO0k702GsRi-h8BEY08kpf5FzMxi_MvRygNXJCyFnbtaC-a59w@mail.gmail.com>]
[parent not found: <87v7wd9a2h.fsf@localhost>]
[parent not found: <878qt7fbki.fsf@gmail.com>]
[parent not found: <87o71jwdxz.fsf@localhost>]
[parent not found: <87wmg6edr0.fsf@gmail.com>]
* [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?) [not found] ` <87wmg6edr0.fsf@gmail.com> @ 2024-12-13 18:41 ` Ihor Radchenko 2024-12-13 22:09 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? Gabriel Santos ` (4 more replies) 0 siblings, 5 replies; 14+ messages in thread From: Ihor Radchenko @ 2024-12-13 18:41 UTC (permalink / raw) To: Tor-björn Claesson, emacs-devel Cc: emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi, Justin Burkett TL;DR: We are in the process of designing a more unified selection interface for Org mode and want to see if there is some way to unify context-menu-mode, transient, which-key and embark together. The idea is to (1) avoid too many customizations; (2) allow users to decide how to choose between multiple options - by mouse, keyboard, and using customizable UIs. Dear all, I have raised the topic of refactoring Org mode menu systems during EmacsConf in https://emacsconf.org/2024/talks/org-update/ The initial idea was replacing the self-written menu code in Org with built-in transient.el. Later, during OrgMeetup a number of people raised concerns that transient may sometimes be an overkill, and that some people may prefer alternative UIs. In particular, embark and context-menu-mode were mentioned. (I am CCing the discussion participants and potentially interested maintainers) In Org mode (although not only in Org mode, looking at the success of embark.el), we often have a UI model where users call an "action" command (like org-ctrl-c-ctrl-c or org-open-at-point) followed by interactive selection among multiple actions. For example, org-open-at-point on a heading with multiple links inside will raise a section buffer listing all the links - pressing a number will open the corresponding link. Another example (see the example patch below), which is a work-in-progress patch for Org citation system, is "following" a citation. To "follow" citation may mean multiple things including but not limited to: (1) going to citation record in the bibliography file; (2) following URL; (3) downloading .pdf file for a citation; etc. **The list of "follow" actions may be customized by users** The general UI flow in these scenarios will be: 1. User calls "action" with cursor at certain syntax element 2. Action menu is displayed, showing the available actions/targets (dynamically built) 3. User selects the action/target This UI flow can be implemented using context menus, which-key popups, transient menus, and also using embark (where the way menu is displayed can be customized). All the 4 approaches represent different UI models with various strengths and weaknesses: - transient has a very flexible layout builder where the menu items can be arranged granularly, but intercepts the main loop disrupting certain keyboard-based workflows - which-key does not stand on the way and integrates well into Emacs' key binding model, but provides little flexibility for menu layout - embark stays in the middle between which-key and transient, making use of transient keymaps and allowing a custom menu renderer - context-menu-mode provides mouse experience 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. WDYT? Best, Ihor Tor-björn Claesson <tclaesson@gmail.com> writes: > From 7e9e0c64fbda2dcb67d8c8421d1c9923ca93e8b4 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Tor-bj=C3=B6rn=20Claesson?= <torb@barbar.claesson.fi> > Date: Tue, 12 Nov 2024 11:09:16 +0200 > Subject: [PATCH] lisp/oc-basic.el: Transient menu for following citations > > * lisp/oc-basic.el (require 'transient): Pull in transient. > (require 'org-element): Pull in org-element. > (org-cite-basic-follow-ask): New customization option. should > `org-cite-basic-follow' prompt the user for an action? > (org-cite-basic-follow-actions): New customization option, that > specifies the contents of the transient menu. > (org-cite-basic--get-key): New function. Get citation key from > citation or citation reference. > (org-cite-basic-follow): New function. Displays a menu asking how to > follow a citation if `org-cite-basic-follow-ask' is > non-nil. Otherwise, it retains the default behaviour of opening the > bibliography entry. This can be inversed with a negative prefix argument. > (org-cite-basic-follow--parse-suffix-specification and > org-cite-basic-follow--setup): Helper functions for > `org-cite-basic-follow'. > (org-cite-register-processor 'basic): Update the basic citation > processor to follow citations using `org-cite-basic-follow'. > > * etc/ORG_NEWS (Menu for choosing how to follow citations): Describe > the new feature > (New option ~org-cite-basic-follow-ask~): Describe this new > customization option. > (New option ~org-cite-basic-follow-actions~): Describe this new > customization option, which specifies the layout of the > `org-cite-basic-follow' transient menu. > > This change was co-authored with much support from Ihor Radchenko and > Jonas Bernoulli, thanks! > --- > etc/ORG-NEWS | 22 +++++++++ > lisp/oc-basic.el | 115 +++++++++++++++++++++++++++++++++++++++++++---- > 2 files changed, 128 insertions(+), 9 deletions(-) > > diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS > index de4f11b25..bacc38be2 100644 > --- a/etc/ORG-NEWS > +++ b/etc/ORG-NEWS > @@ -114,6 +114,15 @@ The keybindings in the repeat-maps can be changed by customizing > > See the new [[info:org#Repeating commands]["Repeating commands"]] section in Org mode manual. > > +*** New transient menu when following citations > + > +Following citations with the org-cite-basic citation backend can now present a > +transient menu. To show this menu, set ~org-cite-basic-follow-ask~ to non-nil. > +This behaviour can be reversed with a -4 prefix. > + > +The contents of this menu can be customized in > +~org-cite-basic-follow-actions~. > + > ** New and changed options > > # Chanes deadling with changing default values of customizations, > @@ -158,6 +167,19 @@ English. The default value is ~t~ as the CSL standard assumes that > English titles are specified in sentence-case but the bibtex > bibliography format requires them to be written in title-case. > > +*** New option ~org-cite-basic-follow-ask~ > + > +When this option is non-nil, following a citation with the basic citation > +backend will present a transient menu with choices for how to follow the > +citation. > +If nil, following a citation will open its bibliography entry. > + > +This behaviour can be reversed with a -4 prefix argument. > + > +*** New option ~org-cite-basic-follow-actions~ > + > +This option specifies the options presented by ~org-cite-basic-follow~. > + > ** New functions and changes in function arguments > > # This also includes changes in function behavior from Elisp perspective. > diff --git a/lisp/oc-basic.el b/lisp/oc-basic.el > index e207a1997..fc55d3a32 100644 > --- a/lisp/oc-basic.el > +++ b/lisp/oc-basic.el > @@ -74,6 +74,8 @@ > (require 'map) > (require 'oc) > (require 'seq) > +(require 'transient) > +(require 'org-element) > > (declare-function org-open-at-point "org" (&optional arg)) > (declare-function org-open-file "org" (path &optional in-emacs line search)) > @@ -140,6 +142,39 @@ > :type 'face > :safe #'facep) > > +(defcustom org-cite-basic-follow-ask nil > + "Should `org-cite-basic' ask how to follow citations? > + > +When this option is nil, `org-cite-basic-follow' opens the bibliography entry. > +Otherwise, `org-cite-basic-follow' will display a transient menu prompting the > +user for an action. The contents of this menu can be customized in > +`org-cite-basic-follow-actions'." > + :group 'org-cite > + :package-version '(Org . "9.8") > + :type 'boolean) > + > +(defcustom org-cite-basic-follow-actions > + '[["Open" > + ("b" "bibliography entry" (org-cite-basic-goto !citation !prefix))] > + ["Copy" > + ("d" "DOI" > + (kill-new > + (org-cite-basic--get-field > + 'doi > + (org-cite-basic--get-key !citation))))]] > + "Actions in the `org-cite-basic-follow' transient menu. > + > +This option uses the same syntax as `transient-define-prefix', see Info node > +`(transient)Binding Suffix and Infix Commands'. In addition, it is possible > +to specify a function call for the COMMAND part, where !citation (the citation > +object to be followed) and !prefix (any prefix argument to the follower) can be > +used to access those values. For example: > +(org-cite-basic-goto !citation !prefix) or > +(lambda () (message (org-element-property :key !citation)))" > + :group 'org-cite > + :package-version '(Org . "9.8") > + :type 'sexp) > + > \f > ;;; Internal variables > (defvar org-cite-basic--bibliography-cache nil > @@ -326,6 +361,16 @@ INFO is the export state, as a property list." > (map-keys entries)) > (org-cite-basic--parse-bibliography))) > > +(defun org-cite-basic--get-key (citation-or-citation-reference) > + "Return citation key for CITATION." > + (if (org-element-type-p citation-or-citation-reference 'citation-reference) > + (org-element-property :key citation-or-citation-reference) > + (pcase (org-cite-get-references citation-or-citation-reference t) > + (`(,key) key) > + (keys > + (or (completing-read "Select citation key: " keys nil t) > + (user-error "Aborted")))))) > + > (defun org-cite-basic--get-entry (key &optional info) > "Return BibTeX entry for KEY, as an association list. > When non-nil, INFO is the export state, as a property list." > @@ -805,14 +850,7 @@ export state, as a property list." > When DATUM is a citation reference, open bibliography entry referencing > the citation key. Otherwise, select which key to follow among all keys > present in the citation." > - (let* ((key > - (if (org-element-type-p datum 'citation-reference) > - (org-element-property :key datum) > - (pcase (org-cite-get-references datum t) > - (`(,key) key) > - (keys > - (or (completing-read "Select citation key: " keys nil t) > - (user-error "Aborted")))))) > + (let* ((key (org-cite-basic--get-key datum)) > (file > (pcase (seq-find (pcase-lambda (`(,_ . ,entries)) > (gethash key entries)) > @@ -832,6 +870,65 @@ present in the citation." > (bibtex-set-dialect) > (bibtex-search-entry key))))) > > +(transient-define-prefix org-cite-basic-follow (citation-object &optional prefix) > + "Follow citation. > + > +If `org-cite-basic-follow-ask' is non-nil, this transient will present > +a menu prompting the user for an action. > +Otherwise, it will open the bibliography entry for the citation at point. > +This behaviour is inverted when the transient is called with a -4 prefix > +argument. > + > +The contents of the menu are defined in the variable > +`org-cite-basic-follow-actions'." > + [:class transient-columns > + :setup-children org-cite-basic-follow--setup > + :pad-keys t] > + (interactive > + (list (let ((obj (org-element-context))) > + (pcase (org-element-type obj) > + ((or 'citation 'citation-reference) obj) > + (_ (user-error "No citation at point")))))) > + (if (xor org-cite-basic-follow-ask > + (equal prefix '(-4))) > + (transient-setup 'org-cite-basic-follow nil nil > + :scope (list :citation citation-object :prefix prefix)) > + (org-cite-basic-goto citation-object prefix))) > + > +(defun org-cite-basic-follow--parse-suffix-specification (specification) > + "Handle special syntax for `org-cite-basic-follow-actions'." > + (pcase specification > + (`(,key ,desc (lambda ,args . ,fn-args) . ,other) > + `(,key ,desc > + (lambda ,args > + ,(unless (and (listp (car fn-args)) > + (equal (caar fn-args) > + 'interactive)) > + '(interactive)) > + (let ((!citation (plist-get (transient-scope) :citation)) > + (!prefix (plist-get (transient-scope) :prefix))) > + ,@fn-args)) > + ,@other)) > + (`(,key ,desc (,fn . ,fn-args) . ,other) > + `(,key ,desc > + (lambda () > + (interactive) > + (let ((!citation (plist-get (transient-scope) :citation)) > + (!prefix (plist-get (transient-scope) :prefix))) > + (,fn ,@fn-args))) > + ,@other)) > + (other other))) > + > +(defun org-cite-basic-follow--setup (_) > + "Update `org-cite-basic-follow' when `org-cite-basic-follow-actions' changes." > + (transient-parse-suffixes > + 'org-cite-basic-follow > + (cl-map 'vector > + (lambda (group) > + (cl-map 'vector #'org-cite-basic-follow--parse-suffix-specification > + group)) > + org-cite-basic-follow-actions))) > + > \f > ;;; "Insert" capability > (defun org-cite-basic--complete-style (_) > @@ -920,7 +1017,7 @@ Raise an error when no bibliography is set in the buffer." > :activate #'org-cite-basic-activate > :export-citation #'org-cite-basic-export-citation > :export-bibliography #'org-cite-basic-export-bibliography > - :follow #'org-cite-basic-goto > + :follow #'org-cite-basic-follow > :insert (org-cite-make-insert-processor #'org-cite-basic--complete-key > #'org-cite-basic--complete-style) > :cite-styles > -- > 2.46.0 > -- Ihor Radchenko // yantar92, Org mode maintainer, 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? 2024-12-13 18:41 ` [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?) Ihor Radchenko @ 2024-12-13 22:09 ` Gabriel Santos 2024-12-14 9:57 ` Ihor Radchenko 2024-12-13 22:57 ` Suhail Singh ` (3 subsequent siblings) 4 siblings, 1 reply; 14+ messages in thread From: Gabriel Santos @ 2024-12-13 22:09 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-devel, emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 6022 bytes --] Greetings, I'll go through the examples found on this e-mail and suggest the menu command I find best for the proposed scenarios. Below is how I think these options could be used. context-menu-mode No particular target, should mostly be used for actions on the whole buffer or on a region, or all particular elements defined. Example: Org -> Headings -> Demote Headings transient Also no particular target, but should be used for commands that would require a menu for interaction, such as exporting and capturing. Example 1: org-export-*dispatch* -> transient menu Example 2: org-capture -> transient menu Example 3: org-attach -> transient menu which-key On a target, list actions that could be performed on it. embark Can be used to replace which-key in customization. But, despite saying this, I have it configured to use which-key as its menu. Ihor Radchenko <yantar92@posteo.net> writes: > I have raised the topic of refactoring Org mode menu systems during > EmacsConf in <https://emacsconf.org/2024/talks/org-update/> I saw the talk live, really excited for the future of Org! > The initial idea was replacing the self-written menu code in Org with > built-in transient.el. > > Later, during OrgMeetup a number of people raised concerns that > transient may sometimes be an overkill, and that some people may prefer > alternative UIs. In particular, embark and context-menu-mode were > mentioned. Personally, I'd prefer for built-in packages/functionality to be considered first. The consideration for context-menu for me is particularly intriguing, as there's a lot of functionality already included in Org's context menu. > (I am CCing the discussion participants and potentially interested > maintainers) Hope to see their responses to this. I'm just a common user, so my opinions should be taken with a grain of salt. > In Org mode (although not only in Org mode, looking at the success of > embark.el), we often have a UI model where users call an "action" > command (like org-ctrl-c-ctrl-c or org-open-at-point) followed by > interactive selection among multiple actions. I don't often use org-ctrl-c-ctrl-c, but now that I've seen the interaction menu for properties as an example, I'd say the best option for it would be which-key, as it's a simpler menu. > For example, org-open-at-point on a heading with multiple links inside > will raise a section buffer listing all the links - pressing a number > will open the corresponding link. I'd consider which-key again for this. > Another example (see the example patch below), which is a > work-in-progress patch for Org citation system, is "following" a > citation. To "follow" citation may mean multiple things including but > not limited to: (1) going to citation record in the bibliography file; > (2) following URL; (3) downloading .pdf file for a citation; etc. > **The list of "follow" actions may be customized by users** This is similar to the functions available in the following package: <https://github.com/emacs-citar/citar> It also allows for opening the bibliography, links, notes, and files connected to the citation. I use it with embark: <https://github.com/emacs-citar/citar/blob/main/citar-embark.el> > The general UI flow in these scenarios will be: > > 1. User calls "action" with cursor at certain syntax element > 2. Action menu is displayed, showing the available actions/targets (dynamically built) > 3. User selects the action/target I'm not sure what the best option would be for displaying targets, but which-key should be able to cover most cases that would require "simpler" menus for actions. I'd also add in that it could be considered over transient if its dynamically built. I tend to associate transient with "static" options. > This UI flow can be implemented using context menus, which-key popups, > transient menus, and also using embark (where the way menu is displayed > can be customized). > > All the 4 approaches represent different UI models with various > strengths and weaknesses: > > - transient has a very flexible layout builder where the menu items can > be arranged granularly, but intercepts the main loop disrupting > certain keyboard-based workflows > - which-key does not stand on the way and integrates well into Emacs' > key binding model, but provides little flexibility for menu layout It has options for setting the pop-up type and position. Could this help with flexibility? > - embark stays in the middle between which-key and transient, making use > of transient keymaps and allowing a custom menu renderer > - context-menu-mode provides mouse experience > > 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. I'd say that this is the best options out of all of them, but, as you said: > "I am wondering if we can work out [...]" This would require considerable work. > 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. > > WDYT? > > Best, > Ihor On this described state (list of actions), which-key would be the best option according to my definition. But, on the current state of org-open-at-point (shows more targets), as I commented previously, there's no menu that I associate with: "Act on target, display a list of other targets." Maybe context-menu would be the closest one, but I wouldn't consider which-key or embark, these are more related to functions. Regards, -- *Gabriel Santos* ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? 2024-12-13 22:09 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? Gabriel Santos @ 2024-12-14 9:57 ` Ihor Radchenko 2024-12-14 10:59 ` Gabriel Santos 0 siblings, 1 reply; 14+ messages in thread From: Ihor Radchenko @ 2024-12-14 9:57 UTC (permalink / raw) To: Gabriel Santos; +Cc: emacs-devel, emacs-orgmode Gabriel Santos <gabrielsantosdesouza@disroot.org> writes: > context-menu-mode > No particular target, should mostly be used for actions on > the whole buffer or on a region, or all particular elements > defined. > > Example: Org -> Headings -> Demote Headings > ... > Personally, I'd prefer for built-in packages/functionality to be considered first. We will definitely try to support built-ins first and foremost. I mentioned embark as an example of alternative UI. Also, embark might be a candidate for upstreaming. > The consideration for context-menu for me is particularly intriguing, as there's > a lot of functionality already included in Org's context menu. This is not right. I think you are confusing ordinary menu bar and context menu. Context menu is "right click" menu that will display different items depending on where you click. Org mode currently does not have context-menu-mode integration (we should fix this deficiency) > I don't often use org-ctrl-c-ctrl-c, but now that I've seen the interaction > menu for properties as an example, I'd say the best option for it would be > which-key, as it's a simpler menu. My conclusion so far is that there is no "best" for every user. We should ideally support user-customized menu UI. The main question is how to do it. >> This UI flow can be implemented using context menus, which-key popups, >> transient menus, and also using embark (where the way menu is displayed >> can be customized). >> >> All the 4 approaches represent different UI models with various >> strengths and weaknesses: > ... > It has options for setting the pop-up type and position. Could this help with > flexibility? May you elaborate what "it" refers to? -- Ihor Radchenko // yantar92, Org mode maintainer, 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? 2024-12-14 9:57 ` Ihor Radchenko @ 2024-12-14 10:59 ` Gabriel Santos 2024-12-14 13:10 ` Ihor Radchenko 0 siblings, 1 reply; 14+ messages in thread From: Gabriel Santos @ 2024-12-14 10:59 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-devel, emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1658 bytes --] >> The consideration for context-menu for me is particularly intriguing, as there's >> a lot of functionality already included in Org's context menu. > > This is not right. I think you are confusing ordinary menu bar and > context menu. Context menu is "right click" menu that will display > different items depending on where you click. Org mode currently does > not have context-menu-mode integration (we should fix this deficiency) Maybe it's some third-party package I'm using, but right-cliking on an Org buffer gives me a lot of options: <https://0x0.st/XF1y.png> >> I don't often use org-ctrl-c-ctrl-c, but now that I've seen the interaction >> menu for properties as an example, I'd say the best option for it would be >> which-key, as it's a simpler menu. > > My conclusion so far is that there is no "best" for every user. We > should ideally support user-customized menu UI. The main question is how > to do it. I also agree with this conclusion. Hope others can contribute with suggestions of how to go about it. >>> This UI flow can be implemented using context menus, which-key popups, >>> transient menus, and also using embark (where the way menu is displayed >>> can be customized). >>> >>> All the 4 approaches represent different UI models with various >>> strengths and weaknesses: >> ... >> It has options for setting the pop-up type and position. Could this help with >> flexibility? > > May you elaborate what "it" refers to? Sorry, seems I forgot to clarify. "It" in this context was referring to which-key. It has the following variables for altering (window) display: - which-key-popup-type - which-key-side-window-location ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? 2024-12-14 10:59 ` Gabriel Santos @ 2024-12-14 13:10 ` Ihor Radchenko 0 siblings, 0 replies; 14+ messages in thread From: Ihor Radchenko @ 2024-12-14 13:10 UTC (permalink / raw) To: Gabriel Santos; +Cc: emacs-devel, emacs-orgmode Gabriel Santos <gabrielsantosdesouza@disroot.org> writes: > Maybe it's some third-party package I'm using, but right-cliking on an Org > buffer gives me a lot of options: > > <https://0x0.st/XF1y.png> This is simply a copy of the top-level menu. You would see the same if you enable the menu bar. No "context" is considered in this case. -- Ihor Radchenko // yantar92, Org mode maintainer, 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? 2024-12-13 18:41 ` [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?) Ihor Radchenko 2024-12-13 22:09 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? Gabriel Santos @ 2024-12-13 22:57 ` Suhail Singh 2024-12-14 9:59 ` Ihor Radchenko 2024-12-14 1:16 ` [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?) Panayotis Manganaris ` (2 subsequent siblings) 4 siblings, 1 reply; 14+ messages in thread From: Suhail Singh @ 2024-12-13 22:57 UTC (permalink / raw) To: Ihor Radchenko Cc: Tor-björn Claesson, emacs-devel, emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi, Justin Burkett Ihor Radchenko <yantar92@posteo.net> writes: > 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. > > WDYT? By "display string" do you mean a description of the action? Or would that be additional? Hopefully, the description of each action will be a first-class member of the "List of possible actions". Or is the intent that the description be taken from the form representing an action (e.g. a defun, a lambda etc). -- Suhail ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? 2024-12-13 22:57 ` Suhail Singh @ 2024-12-14 9:59 ` Ihor Radchenko 2024-12-14 14:30 ` Suhail Singh 0 siblings, 1 reply; 14+ messages in thread From: Ihor Radchenko @ 2024-12-14 9:59 UTC (permalink / raw) To: Suhail Singh Cc: Tor-björn Claesson, emacs-devel, emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi, Justin Burkett Suhail Singh <suhailsingh247@gmail.com> writes: >> 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. > > By "display string" do you mean a description of the action? Or would > that be additional? I mean some way to define how the action should be displayed in the menu. It may be a full string or just a description to be appended to the action name, or something else. > Hopefully, the description of each action will be a first-class member > of the "List of possible actions". Or is the intent that the > description be taken from the form representing an action (e.g. a defun, > a lambda etc). Using a docstring sounds like a good idea. But it is a bit early to decide these details. I'd like to discuss the more general design first. -- Ihor Radchenko // yantar92, Org mode maintainer, 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? 2024-12-14 9:59 ` Ihor Radchenko @ 2024-12-14 14:30 ` Suhail Singh 0 siblings, 0 replies; 14+ messages in thread From: Suhail Singh @ 2024-12-14 14:30 UTC (permalink / raw) To: Ihor Radchenko Cc: Suhail Singh, Tor-björn Claesson, emacs-devel, emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi, Justin Burkett Ihor Radchenko <yantar92@posteo.net> writes: >> Hopefully, the description of each action will be a first-class member >> of the "List of possible actions". Or is the intent that the >> description be taken from the form representing an action (e.g. a defun, >> a lambda etc). > > Using a docstring sounds like a good idea. But it is a bit early to > decide these details. I'd like to discuss the more general design first. I agree that it may be premature to think about implementation details of how docstrings are stored etc. However, I would like to ensure that any discussion of the design of ways-to-choose-an-action-at-point include self-documentation and self-discovery in the desiderata. Perhaps this goes without saying, in which case please ignore this message. However, it's too important to be left to chance. -- Suhail ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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?) 2024-12-13 18:41 ` [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?) Ihor Radchenko 2024-12-13 22:09 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? Gabriel Santos 2024-12-13 22:57 ` Suhail Singh @ 2024-12-14 1:16 ` Panayotis Manganaris 2024-12-14 10:08 ` Ihor Radchenko 2024-12-14 10:50 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? indieterminacy 2024-12-14 17:53 ` Juri Linkov 4 siblings, 1 reply; 14+ messages in thread From: Panayotis Manganaris @ 2024-12-14 1:16 UTC (permalink / raw) To: Ihor Radchenko, Tor-björn Claesson, emacs-devel Cc: emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi, Justin Burkett Hello. I'm very much an elisp amateur, but one of my main motives for learning has been to make use of emacs' many beautiful UI systems. Therefore, I'll provide my comments from a designer perspective and avoid implementation detail. Ihor Radchenko <yantar92@posteo.net> writes: > TL;DR: We are in the process of designing a more unified selection > interface for Org mode Thanks to Tor-björn, Jonas, Ihor, and everyone else for this work. I've learned much by following this thread. > a number of people raised concerns that transient may sometimes be an > overkill I agree with others that transient is overkill for most of the menus in org-mode. A counter argument, going by the patches exchanged here, might be that transient menus are a clean and scalable approach. I've not tried the in-dev transient follow processor, but I imagine it is similar to the old org-ref (John Kitchin) hydra menu. I used org-ref for years, and enjoyed how its menu united many features, including - a system analogous to org-cite follow processors for navigating to sources/notes - a system akin to reftex-mode for org - a system for downloading new references and making new bibliography entries With this level of complexity, a transient menu seems like the modern weapon of choice for a similar feature set. Only, wait, I stopped using org-ref. Long story short, I concluded that treating org-mode like a nexus for these intertwined features was, at least, encouraging my bad habit of treating org-mode as an "everything app." I have since delegated the task of populating my personal library to a dedicated reference manager. I started using latex-mode and reftex to write papers, thus gaining more typesetting control and making version management much easier. I still use org to take notes, but now enjoy a much more stable and focused configuration. I tell this story as an (anecdotal) case study for how a powerful menu can be less productive in the long run. Org-ref's hydra menu is not to blame for my bad decisions but, at least in-part, I used it (and even extended it) because a greater man put it there. Scalable design is an invitation to scale. Perhaps the wise know better. Anyway, the simple tasks of navigating from a citation link to a copy of the original document, its URL, or an associated note is achievable with a completing-read (helm, counsel, vertico, etc.) interface. Transient is overkill. > This UI flow can be implemented using context menus [...] embark I like org's context menus, but I like embark better. I do think it would be very generous of org to delegate its own contextual actions to embark if so configured. I'll elaborate: As is, I like to run org-babel code block functions through embark, I only wish there were more of them to run. I find this to be far superior in every way to binding equivalent key chords for the mode. Also, for me, embark-bindings and embark-prefix-help-command have completely replaced which-key for discovering key bindings on-the-fly. > 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. I support this idea in principle. > 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. I would focus on associating just enough metadata with functions to enable using them with embark. I really have no idea what the best way to do this is. This seems to be the biggest missing piece. Maybe in the short term we just crowd-source some embark configuration on WORG. Menus should of course be useful without embark. If the goal here is to deprecate many of org's ad-hoc interfaces, I think the natural default replacement for most is completing-read. I may be completely wrong. > 2. Menu interface to use (transient, context-menu, embark, which-key) It seems like Tor-björn and Ihor have already laid the groundwork for using transient in this way. So, I'll just say bravo. Regardless of my opinion on transient overuse, it looks like great work. On the other hand, e.g. if the org export dispatch menu isn't transient, it should be. Seems obvious to me. > 3. Layout settings for the specific interfaces. For example, transient > layout definition. It is important to avoid making more org-mode-specific UI abstractions. Whatever the solution, it is important that the UI implementations tapped to take over help share the maintenance burden. In this way, I reckon most interface customization can be done in hooks. > WDYT? Ideally org-mode uses established APIs rather than making another. Thanks for reading, and thanks for the chance to contribute. ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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?) 2024-12-14 1:16 ` [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?) Panayotis Manganaris @ 2024-12-14 10:08 ` Ihor Radchenko 0 siblings, 0 replies; 14+ messages in thread From: Ihor Radchenko @ 2024-12-14 10:08 UTC (permalink / raw) To: Panayotis Manganaris Cc: Tor-björn Claesson, emacs-devel, emacs-orgmode, Philip Kaludercic, Omar Antolín Camarena, Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh, Justin Burkett Panayotis Manganaris <panos.manganaris@gmail.com> writes: > Menus should of course be useful without embark. If the goal here is to > deprecate many of org's ad-hoc interfaces, I think the natural default > replacement for most is completing-read. I may be completely wrong. For the existing interfaces, we are not going to change things in incompatible ways. The idea is to keep the existing menus working as similarly as possible compared to the current ad-hoc menus. So, no, we are not going to replace things with completing-read. Not by default. But what I hope to see is a way for users to customize the UI to their preference. Without touching the defaults. > On the other hand, e.g. if the org export dispatch menu isn't transient, > it should be. Seems obvious to me. Yes. That's where we will have to use transient. This discussion mostly concerns simpler cases when user needs to choose from a list. -- Ihor Radchenko // yantar92, Org mode maintainer, 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? 2024-12-13 18:41 ` [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?) Ihor Radchenko ` (2 preceding siblings ...) 2024-12-14 1:16 ` [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?) Panayotis Manganaris @ 2024-12-14 10:50 ` indieterminacy 2024-12-14 17:53 ` Juri Linkov 4 siblings, 0 replies; 14+ messages in thread From: indieterminacy @ 2024-12-14 10:50 UTC (permalink / raw) To: Ihor Radchenko Cc: Tor-björn Claesson, emacs-devel, emacs-orgmode, Omar Antolín Camarena, Jonas Bernoulli, Juri Linkov, karthikchikmagalur, Visuwesh, charles.choi, Justin Burkett, rswgnu Hello Ihor, On 2024-12-13 19:41, Ihor Radchenko wrote: > TL;DR: We are in the process of designing a more unified selection > interface for Org mode and want to see if there is some way to unify > context-menu-mode, transient, which-key and embark together. The idea > is > to (1) avoid too many customizations; (2) allow users to decide how to > choose between multiple options - by mouse, keyboard, and using > customizable UIs. > ... I would consider an `actions -> menu` functionality to be something which should be a distinct tool, albeit heavily configured to suit Orgmode functionality. I think its great how Transient was able to emerge from Magit's activities and its clearly providing opportunities for scaling the utility. If I may widen the topic a little, your RFC could be an opportunity to examine the overlaps between Orgmode and Hyperbole. For instance, the use of implicit buttons could be examined: https://www.gnu.org/software/hyperbole/man/hyperbole.html#Implicit-Buttons I reckon what you are proposing (greater fluency and flow for menus dependent on context) could benefit Hyperbole's functionality too (the action utility for that environment seems more focused on one action rather than prompting a selection of actions). Ive CC'd Robert Weiner (who leads Hyperbole), incase that is of use. Kind regards, Jonathan McHugh ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? 2024-12-13 18:41 ` [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?) Ihor Radchenko ` (3 preceding siblings ...) 2024-12-14 10:50 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? indieterminacy @ 2024-12-14 17:53 ` Juri Linkov 4 siblings, 0 replies; 14+ messages in thread From: Juri Linkov @ 2024-12-14 17:53 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-devel, emacs-orgmode > 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) This looks like the best design. Any part of the org buffer could have text properties with a list of its available actions. Such a property could be similar to 'context-menu-functions' handled by 'context-menu-map'. But since it will be a plain generic list, it could be transformed to any menu interface such as transient, context-menu, etc. To transform it to context-menu, org-mode should provide a function like 'context-menu-minor' that will create a corresponding menu that will be added as a submenu of the default context menu. Such integration with existing menus would be better than the current implementation of context menus in org-mouse-context-menu that completely replaces the context menu with its own. ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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?) @ 2024-12-14 0:37 Psionic K 2024-12-14 9:48 ` Ihor Radchenko 0 siblings, 1 reply; 14+ messages in thread From: Psionic K @ 2024-12-14 0:37 UTC (permalink / raw) To: Ihor Radchenko Cc: charles.choi, Emacs developers, emacs-orgmode, emacs.transient, juri, justin, karthikchikmagalur, omar, Philip Kaludercic, tclaesson, visuweshm [-- Attachment #1: Type: text/plain, Size: 4497 bytes --] > 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 [-- Attachment #2: Type: text/html, Size: 4850 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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?) 2024-12-14 0:37 [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?) Psionic K @ 2024-12-14 9:48 ` Ihor Radchenko 2024-12-14 10:12 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? Philip Kaludercic 0 siblings, 1 reply; 14+ messages in thread From: Ihor Radchenko @ 2024-12-14 9:48 UTC (permalink / raw) To: Psionic K Cc: charles.choi, Emacs developers, emacs-orgmode, emacs.transient, juri, justin, karthikchikmagalur, omar, Philip Kaludercic, tclaesson, visuweshm Psionic K <psionik@positron.solutions> writes: >> 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. Thanks for the info! So, we can have something like :transient-non-suffix 'leave and then pressing something that is not bound to a suffix or infix will run the parent keymap command, automatically leaving transient state. > - Normalizing how to obtain arguments when being called independently as an > interactive command versus being called as a Transient suffix I think it is addressed in the example patch I shared. There, we pass around the original function arguments via macro expansion (!arg-name) ["Open" ("b" "bibliography entry" (org-cite-basic-goto !citation !prefix))] > 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. This is also partially solved. We do use :setup-children, although the initial implementation simply reads user customization into menu layout. I believe that we can read a keymap in similar way and generate transient layout automatically. > 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. May you please elaborate? -- Ihor Radchenko // yantar92, Org mode maintainer, 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? 2024-12-14 9:48 ` Ihor Radchenko @ 2024-12-14 10:12 ` Philip Kaludercic 0 siblings, 0 replies; 14+ messages in thread From: Philip Kaludercic @ 2024-12-14 10:12 UTC (permalink / raw) To: Ihor Radchenko Cc: Psionic K, charles.choi, Emacs developers, emacs-orgmode, emacs.transient, juri, justin, karthikchikmagalur, omar, tclaesson, visuweshm Can I please be removed from the CCs in this thread? Ihor Radchenko <yantar92@posteo.net> writes: > Psionic K <psionik@positron.solutions> writes: > >>> 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. > > Thanks for the info! > So, we can have something like > > :transient-non-suffix 'leave > > and then pressing something that is not bound to a suffix or infix will > run the parent keymap command, automatically leaving transient state. > >> - Normalizing how to obtain arguments when being called independently as an >> interactive command versus being called as a Transient suffix > > I think it is addressed in the example patch I shared. There, we pass > around the original function arguments via macro expansion (!arg-name) > > ["Open" ("b" "bibliography entry" (org-cite-basic-goto !citation !prefix))] > >> 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. > > This is also partially solved. We do use :setup-children, although the > initial implementation simply reads user customization into menu layout. > > I believe that we can read a keymap in similar way and generate > transient layout automatically. > >> 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. > > May you please elaborate? ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-12-14 17:53 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <8734m28l9a.fsf@gmail.com> [not found] ` <874j6h3rw8.fsf@localhost> [not found] ` <877cbamq2q.fsf@gmail.com> [not found] ` <87cykvrgwr.fsf@localhost> [not found] ` <8734lpmkjn.fsf@gmail.com> [not found] ` <87r08lqlbu.fsf@localhost> [not found] ` <87a5ewfvo1.fsf@gmail.com> 2024-10-22 17:58 ` Org-cite: Replace basic follow-processor with transient menu? Ihor Radchenko [not found] ` <87wmhlmp83.fsf@gmail.com> [not found] ` <871pzte929.fsf@localhost> [not found] ` <87v7x548ri.fsf@gmail.com> [not found] ` <87y120daue.fsf@localhost> [not found] ` <874j4m9ep6.fsf@gmail.com> [not found] ` <87h68gfqj1.fsf@localhost> [not found] ` <CAO0k701CGFnQwCCuODjTFuf=OTsj9Vdqg+COP8nkpJg0wL_hQg@mail.gmail.com> [not found] ` <87pln3f3cc.fsf@localhost> [not found] ` <CAO0k7006goK-AfhG+3PVwhz=4QU_DMm+5edmATZpjdRHkj61Bg@mail.gmail.com> [not found] ` <87jzd9ojj0.fsf@localhost> [not found] ` <87cyj0ajm9.fsf@gmail.com> [not found] ` <87zfm4s50x.fsf@localhost> [not found] ` <CAO0k703a5SCv4Eaogjs-14zgmTi-pK5qqG=8VzB8+7h-kcC8yg@mail.gmail.com> [not found] ` <87wmh8s358.fsf@localhost> [not found] ` <87y11nwp9z.fsf@gmail.com> [not found] ` <CAO0k702GsRi-h8BEY08kpf5FzMxi_MvRygNXJCyFnbtaC-a59w@mail.gmail.com> [not found] ` <87v7wd9a2h.fsf@localhost> [not found] ` <878qt7fbki.fsf@gmail.com> [not found] ` <87o71jwdxz.fsf@localhost> [not found] ` <87wmg6edr0.fsf@gmail.com> 2024-12-13 18:41 ` [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?) Ihor Radchenko 2024-12-13 22:09 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? Gabriel Santos 2024-12-14 9:57 ` Ihor Radchenko 2024-12-14 10:59 ` Gabriel Santos 2024-12-14 13:10 ` Ihor Radchenko 2024-12-13 22:57 ` Suhail Singh 2024-12-14 9:59 ` Ihor Radchenko 2024-12-14 14:30 ` Suhail Singh 2024-12-14 1:16 ` [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?) Panayotis Manganaris 2024-12-14 10:08 ` Ihor Radchenko 2024-12-14 10:50 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? indieterminacy 2024-12-14 17:53 ` Juri Linkov 2024-12-14 0:37 [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?) Psionic K 2024-12-14 9:48 ` Ihor Radchenko 2024-12-14 10:12 ` [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? Philip Kaludercic
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).