* Poll: new keybinding for org-insert-structure-template? @ 2017-12-10 0:23 Eric Abrahamsen 2017-12-10 11:26 ` Rasmus 0 siblings, 1 reply; 36+ messages in thread From: Eric Abrahamsen @ 2017-12-10 0:23 UTC (permalink / raw) To: emacs-orgmode Hello all, Rasmus' org-tempo patch has landed, and it's time to make a few adjustments to org-insert-structure-template: I think we're moving to string keys in the template alist, rather than character keys, and also some people noted that the keybinding "C-c C-x w" is too close to "C-c C-x C-w", which kills a whole subtree. Not a good command to run accidentally! Given that the template system has been re-instated, are there any good suggestions out there for a new keybinding for `org-insert-structure-template'? This is the command that wraps existing text in blocks. Thanks, Eric ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-10 0:23 Poll: new keybinding for org-insert-structure-template? Eric Abrahamsen @ 2017-12-10 11:26 ` Rasmus 2017-12-10 19:37 ` Eric Abrahamsen 0 siblings, 1 reply; 36+ messages in thread From: Rasmus @ 2017-12-10 11:26 UTC (permalink / raw) To: emacs-orgmode Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Hello all, > > Rasmus' org-tempo patch has landed, and it's time to make a few > adjustments to org-insert-structure-template: I think we're moving to > string keys in the template alist, rather than character keys, Let me know when you want me to do the change to strings. > and also > some people noted that the keybinding "C-c C-x w" is too close to "C-c > C-x C-w", which kills a whole subtree. Not a good command to run > accidentally! Two other things that might be nice to changer are - Perhaps there could be a space after at least "#+begin_src" so that it’s ready to insert :keys. - Perhaps there could be a newline between "#+begin_x" and "#+end_x". These things might already have been discussed in which case I missed them. > Given that the template system has been re-instated, are there any good > suggestions out there for a new keybinding for > `org-insert-structure-template'? This is the command that wraps existing > text in blocks. These aren’t too bad to typo on my keyboard: C-c C-. or C-c C-, C-c C-x s might make sense. It’s OKish to type on my keyboard layout, but no harder than C-c C-x C-w. free-keys.el can be used to identify combinations, although it isn’t bullet-proof. Rasmus -- However beautiful the theory, one should occasionally look at the evidence ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-10 11:26 ` Rasmus @ 2017-12-10 19:37 ` Eric Abrahamsen 2017-12-12 7:48 ` Rasmus 0 siblings, 1 reply; 36+ messages in thread From: Eric Abrahamsen @ 2017-12-10 19:37 UTC (permalink / raw) To: emacs-orgmode Rasmus <rasmus@gmx.us> writes: > Eric Abrahamsen <eric@ericabrahamsen.net> writes: > >> Hello all, >> >> Rasmus' org-tempo patch has landed, and it's time to make a few >> adjustments to org-insert-structure-template: I think we're moving to >> string keys in the template alist, rather than character keys, > > Let me know when you want me to do the change to strings. No time like the present! I don't think there's anything else remaining to be done. >> and also >> some people noted that the keybinding "C-c C-x w" is too close to "C-c >> C-x C-w", which kills a whole subtree. Not a good command to run >> accidentally! > > Two other things that might be nice to changer are > > - Perhaps there could be a space after at least "#+begin_src" so that > it’s ready to insert :keys. > - Perhaps there could be a newline between "#+begin_x" and "#+end_x". > > These things might already have been discussed in which case I missed > them. The first was mentioned, not the second; I think they're both good ideas. There's a clause in o-i-s-t that puts point at the begin line for certain structure types, that would be a fine spot to insert a space. >> Given that the template system has been re-instated, are there any good >> suggestions out there for a new keybinding for >> `org-insert-structure-template'? This is the command that wraps existing >> text in blocks. > > These aren’t too bad to typo on my keyboard: C-c C-. or C-c C-, I like either of these... ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-10 19:37 ` Eric Abrahamsen @ 2017-12-12 7:48 ` Rasmus 2017-12-12 7:55 ` Nicolas Goaziou 0 siblings, 1 reply; 36+ messages in thread From: Rasmus @ 2017-12-12 7:48 UTC (permalink / raw) To: emacs-orgmode; +Cc: mail Hi, >> Let me know when you want me to do the change to strings. > > No time like the present! I don't think there's anything else remaining > to be done. One stumbling block is how to input key strings to org-insert-structure-template. Currently, it employs read-key which is really fast. The other easy alternative is completing-read with the keys. However, there you’d have to click RET at the end. The ideal interface for inputting the keys is something like the ox expert export UI. I looked at the code and it seems a bit complex. Nicolas, are there any public interfaces to make ox export like interfaces? Rasmus -- m-mm-mmm-mmmm bacon! ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-12 7:48 ` Rasmus @ 2017-12-12 7:55 ` Nicolas Goaziou 2017-12-12 13:49 ` Rasmus 0 siblings, 1 reply; 36+ messages in thread From: Nicolas Goaziou @ 2017-12-12 7:55 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode Hello, Rasmus <rasmus@gmx.us> writes: > Nicolas, are there any public interfaces to make ox export like > interfaces? No, there isn't. However, Org provides `org-mks'. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-12 7:55 ` Nicolas Goaziou @ 2017-12-12 13:49 ` Rasmus 2017-12-12 14:02 ` Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list) Kaushal Modi 2017-12-13 0:45 ` Poll: new keybinding for org-insert-structure-template? Eric Abrahamsen 0 siblings, 2 replies; 36+ messages in thread From: Rasmus @ 2017-12-12 13:49 UTC (permalink / raw) To: emacs-orgmode Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > Hello, > > Rasmus <rasmus@gmx.us> writes: > >> Nicolas, are there any public interfaces to make ox export like >> interfaces? > > No, there isn't. However, Org provides `org-mks'. Good point. It isn’t quite as nice as the export dispatcher. Let’s wait and see what Eric prefers. Rasmus -- Send from my Emacs ^ permalink raw reply [flat|nested] 36+ messages in thread
* Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list) 2017-12-12 13:49 ` Rasmus @ 2017-12-12 14:02 ` Kaushal Modi 2017-12-12 18:45 ` Key binding popup interface Eric S Fraga ` (2 more replies) 2017-12-13 0:45 ` Poll: new keybinding for org-insert-structure-template? Eric Abrahamsen 1 sibling, 3 replies; 36+ messages in thread From: Kaushal Modi @ 2017-12-12 14:02 UTC (permalink / raw) To: Rasmus, Emacs developers, Oleh Krehel; +Cc: emacs-org list [-- Attachment #1: Type: text/plain, Size: 1454 bytes --] Copying this on both Emacs devel and Org mode list. Hopefully this discussion is eligible for that. Problem statement: Need to have a pretty interface that shows the available valid key bindings. We have something custom developed for Org export interface. Magit has its own popup interface. I know verilog-mode.el has something in-house for picking the skeleton for insertion, but the interface is not as good as hydra's. Projectile.el (not on GNU Elpa) has its projectile commander, another in-house attempt to get a similar pop-up interface. Of all those options and more that I've seen out there, hydra.el looks like the most elegant and *configurable* option. Can hydra.el be merged into Emacs core, so that all the packages can start taking advantage of that? We need to stop having each package develop their own way to do this same thing. It's already on GNU Elpa[1] , so there won't be any legal concerns. [1]: https://elpa.gnu.org/packages/hydra.html On Tue, Dec 12, 2017, 8:50 AM Rasmus <rasmus@gmx.us> wrote: > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > > > Hello, > > > > Rasmus <rasmus@gmx.us> writes: > > > >> Nicolas, are there any public interfaces to make ox export like > >> interfaces? > > > > No, there isn't. However, Org provides `org-mks'. > > Good point. It isn’t quite as nice as the export dispatcher. Let’s wait > and see what Eric prefers. > -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 2170 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 14:02 ` Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list) Kaushal Modi @ 2017-12-12 18:45 ` Eric S Fraga 2017-12-12 18:56 ` Kaushal Modi 2017-12-12 20:20 ` Eric Abrahamsen 2017-12-12 21:01 ` Stefan Monnier 2 siblings, 1 reply; 36+ messages in thread From: Eric S Fraga @ 2017-12-12 18:45 UTC (permalink / raw) To: Kaushal Modi; +Cc: Oleh Krehel, emacs-org list, Rasmus, Emacs developers [-- Attachment #1: Type: text/plain, Size: 373 bytes --] On Tuesday, 12 Dec 2017 at 14:02, Kaushal Modi wrote: > Copying this on both Emacs devel and Org mode list. Hopefully this > discussion is eligible for that. > > Problem statement: Need to have a pretty interface that shows the available > valid key bindings. which-key-mode works well for me. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-206-g1bb9cf [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 194 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 18:45 ` Key binding popup interface Eric S Fraga @ 2017-12-12 18:56 ` Kaushal Modi 2017-12-12 19:53 ` Alan E. Davis 0 siblings, 1 reply; 36+ messages in thread From: Kaushal Modi @ 2017-12-12 18:56 UTC (permalink / raw) To: Rasmus, Emacs developers, Oleh Krehel, emacs-org list, Eric S Fraga [-- Attachment #1: Type: text/plain, Size: 1391 bytes --] On Tue, Dec 12, 2017 at 1:48 PM Eric S Fraga <esflists@gmail.com> wrote: > On Tuesday, 12 Dec 2017 at 14:02, Kaushal Modi wrote: > > Copying this on both Emacs devel and Org mode list. Hopefully this > > discussion is eligible for that. > > > > Problem statement: Need to have a pretty interface that shows the > available > > valid key bindings. > > which-key-mode works well for me. > I use which-key too, but that serves a different purpose. which-key shows *all* bindings that begin with a prefix. hydra creates a quick keymap that can be bound to any key of user's choice. Then the user needs to just set that main binding, and all the sub-bindings in that keymap stay the same. - Hydra basics[1] - Projectile hydra example[2] - Rectangle operations[3] (See many more examples in that wiki.) Very vaguely speaking, which-key is a read-only utility, hydra is a create + read utility. We need the "create" portion for the org stucture template replacement discussed on the Org thread. I understand that while hydra cannot be integrated in emacs 26 and so Org cannot immediately start using it, it will be very much useful to many packages in future if first hydra is baked into the emacs core. [1]: https://github.com/abo-abo/hydra/wiki/Basics [2]: https://github.com/abo-abo/hydra/wiki/Projectile [3]: https://github.com/abo-abo/hydra/wiki/Rectangle-Operations -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 2201 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 18:56 ` Kaushal Modi @ 2017-12-12 19:53 ` Alan E. Davis 0 siblings, 0 replies; 36+ messages in thread From: Alan E. Davis @ 2017-12-12 19:53 UTC (permalink / raw) To: Kaushal Modi Cc: Oleh Krehel, emacs-org list, Eric S Fraga, Rasmus, Emacs developers [-- Attachment #1: Type: text/plain, Size: 2217 bytes --] I discovered accidentally some years ago, when I had been using a popup help function that I cobbled together myself with a hot key, that <Prefix>-F1 loads a list of bindings under that prefix. It's an awesome feature of GNU/Emacs. Alan Davis On Tue, Dec 12, 2017 at 10:56 AM, Kaushal Modi <kaushal.modi@gmail.com> wrote: > On Tue, Dec 12, 2017 at 1:48 PM Eric S Fraga <esflists@gmail.com> wrote: > >> On Tuesday, 12 Dec 2017 at 14:02, Kaushal Modi wrote: >> > Copying this on both Emacs devel and Org mode list. Hopefully this >> > discussion is eligible for that. >> > >> > Problem statement: Need to have a pretty interface that shows the >> available >> > valid key bindings. >> >> which-key-mode works well for me. >> > > I use which-key too, but that serves a different purpose. > > which-key shows *all* bindings that begin with a prefix. > > hydra creates a quick keymap that can be bound to any key of user's > choice. Then the user needs to just set that main binding, and all the > sub-bindings in that keymap stay the same. > > - Hydra basics[1] > - Projectile hydra example[2] > - Rectangle operations[3] > > (See many more examples in that wiki.) > > Very vaguely speaking, which-key is a read-only utility, hydra is a create > + read utility. We need the "create" portion for the org stucture template > replacement discussed on the Org thread. I understand that while hydra > cannot be integrated in emacs 26 and so Org cannot immediately start using > it, it will be very much useful to many packages in future if first hydra > is baked into the emacs core. > > [1]: https://github.com/abo-abo/hydra/wiki/Basics > [2]: https://github.com/abo-abo/hydra/wiki/Projectile > [3]: https://github.com/abo-abo/hydra/wiki/Rectangle-Operations > -- > > Kaushal Modi > -- [Fill in the blanks] The use of corrupt manipulations and blatant rhetorical ploys ...--- outright lying, flagwaving, personal attacks, setting up phony alternatives, misdirection, jargon-mongering, evading key issues, feigning disinterested objectivity, willful misunderstanding of other points of view---suggests that ... lacks both credibility and evidence. ---- Edward Tufte (in context of making presentations) [-- Attachment #2: Type: text/html, Size: 3993 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 14:02 ` Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list) Kaushal Modi 2017-12-12 18:45 ` Key binding popup interface Eric S Fraga @ 2017-12-12 20:20 ` Eric Abrahamsen 2017-12-12 20:33 ` Kaushal Modi 2017-12-12 21:01 ` Stefan Monnier 2 siblings, 1 reply; 36+ messages in thread From: Eric Abrahamsen @ 2017-12-12 20:20 UTC (permalink / raw) To: Kaushal Modi; +Cc: Oleh Krehel, emacs-org list, Rasmus, Emacs developers Kaushal Modi <kaushal.modi@gmail.com> writes: > Copying this on both Emacs devel and Org mode list. Hopefully this discussion is eligible for that. > > Problem statement: Need to have a pretty interface that shows the available valid key bindings. > > We have something custom developed for Org export interface. Magit has its own popup interface. I know verilog-mode.el has something in-house for picking the skeleton for insertion, but the interface is not as good as hydra's. > Projectile.el (not on GNU Elpa) has its projectile commander, another in-house attempt to get a similar pop-up interface. > > Of all those options and more that I've seen out there, hydra.el looks like the most elegant and *configurable* option. > > Can hydra.el be merged into Emacs core, so that all the packages can start taking advantage of that? We need to stop having each package develop their own way to do this same thing. Hydra definitely sounds nice, but unless I'm misunderstanding how it works, it can't be a replacement for either Org's export interface, or Magit's popups. Both of those can set various state variables before choosing an actual action -- Hydra can't do that, can it? Did I hear that Magit was breaking its popup interface out into a separate library? If so, that would also be a nice thing. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 20:20 ` Eric Abrahamsen @ 2017-12-12 20:33 ` Kaushal Modi 2017-12-12 20:44 ` Eric Abrahamsen 0 siblings, 1 reply; 36+ messages in thread From: Kaushal Modi @ 2017-12-12 20:33 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: Oleh Krehel, emacs-org list, Rasmus, Emacs developers [-- Attachment #1.1: Type: text/plain, Size: 4310 bytes --] On Tue, Dec 12, 2017 at 3:20 PM Eric Abrahamsen <eric@ericabrahamsen.net> wrote: > > Hydra definitely sounds nice, but unless I'm misunderstanding how it > works, it can't be a replacement for either Org's export interface, or > Magit's popups. Both of those can set various state variables before > choosing an actual action -- Hydra can't do that, can it? > hydra can do anything you can do in elisp before/after the action. For example, here's a hydra I use for rectangle actions: (defhydra hydra-rectangle (:body-pre (rectangle-mark-mode 1) :color pink :post (deactivate-mark) :hint nil) " Rectangle: ^_p_^ _d_ delete _s_tring _c_/_C_ (delete/kill) and replace with space _b_ _f_ _k_ cut _r_eset _o_pen (create blank rectangle and push text in region to the right) ^_n_^ _w_ copy e_x_change _X_ delete whitespace starting from the left edge of the rectangle ^^^^ _y_ paste _e_xtend Prefix rectangle lines with _N_umbers " ("b" backward-char) ("f" forward-char) ("p" previous-line) ("n" next-line) ("d" delete-rectangle :color blue) ("k" kill-rectangle :color blue) ("w" copy-rectangle-as-kill :color blue) ("y" yank-rectangle :color blue) ("s" string-rectangle :color blue) ("t" string-rectangle :color blue) ("r" (if (region-active-p) (deactivate-mark) (rectangle-mark-mode 1))) ("x" ora-ex-point-mark) ("e" modi/extend-rectangle-to-end) ("c" clear-rectangle) ("C" modi/kill-rectangle-replace-with-space :color blue) ("o" open-rectangle :color blue) ("X" delete-whitespace-rectangle :color blue) ("N" rectangle-number-lines :color blue) ("q" nil "cancel" :color blue)) Note the use of :body-pre, :post in above example. More details here: https://github.com/abo-abo/hydra/wiki/internals#body-pre <https://github.com/abo-abo/hydra/wiki/internals#body-pre> But this email wasn't to propose replace the matured popups like magit and org export with hydra. The proposal is to integrate hydra into emacs, so that many packages that self-implement these popups can do the same using hydra more easily. Dired, ibuffer can make use of hydra and make all the bindings more discoverable and memorable. In future, may be hydra can be use for the org template insertion piece. I can talk of verilog-mode as I use it everyday. In verilog-mode.el, there is this code: (defvar verilog-template-map (let ((map (make-sparse-keymap))) (define-key map "a" 'verilog-sk-always) (define-key map "b" 'verilog-sk-begin) .. (define-key map "D" 'verilog-sk-define-signal) map) "Keymap used in Verilog mode for smart template operations.") In my config, I replace the same with hydra and it looks like this: (defhydra hydra-verilog-template (:color blue :hint nil) " _i_nitial _?_ if _j_ fork _A_ssign _uc_ uvm-component _b_egin _:_ else-if _m_odule _I_nput _uo_ uvm-object _a_lways _f_or _g_enerate _O_utput ^^ _w_hile _p_rimitive _=_ inout ^^ _r_epeat _s_pecify _S_tate-machine _h_eader ^^ _c_ase _t_ask _W_ire _/_ comment ^^ case_x_ _F_unction _R_eg ^^ case_z_ ^^ _D_efine-signal " ("a" verilog-sk-always) ("b" verilog-sk-begin) ... ("D" verilog-sk-define-signal) ("q" nil nil :color blue) ("C-g" nil nil :color blue)) Which gives in these interface which makes the bindings much more memorable and accessible: [image: image.png] There are so many places like this that can get a facelift from hydra. Did I hear that Magit was breaking its popup interface out into a > separate library? If so, that would also be a nice thing. > That would be great too. We are basically missing a configurable library to bind temporary key maps, that can make the bindings present in a discoverable way to the user. So far hydra.el fits the bill. -- Kaushal Modi [-- Attachment #1.2: Type: text/html, Size: 6539 bytes --] [-- Attachment #2: image.png --] [-- Type: image/png, Size: 20877 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 20:33 ` Kaushal Modi @ 2017-12-12 20:44 ` Eric Abrahamsen 2017-12-12 20:56 ` Kaushal Modi 0 siblings, 1 reply; 36+ messages in thread From: Eric Abrahamsen @ 2017-12-12 20:44 UTC (permalink / raw) To: emacs-devel; +Cc: emacs-orgmode Kaushal Modi <kaushal.modi@gmail.com> writes: > On Tue, Dec 12, 2017 at 3:20 PM Eric Abrahamsen <eric@ericabrahamsen.net> wrote: > > Hydra definitely sounds nice, but unless I'm misunderstanding how it > works, it can't be a replacement for either Org's export interface, or > Magit's popups. Both of those can set various state variables before > choosing an actual action -- Hydra can't do that, can it? [...] > But this email wasn't to propose replace the matured popups like magit and org export with hydra. The proposal is to integrate hydra into emacs, so that many packages that self-implement these popups can do the same using hydra > more easily. Dired, ibuffer can make use of hydra and make all the bindings more discoverable and memorable. In future, may be hydra can be use for the org template insertion piece. Okay, interesting. I agree that "discoverable keymaps" and "action dispatchers" (whatever Org and Magit do) aren't quite the same thing, and it would be nice to have both. I guess in the meantime, though, we're still going to have to use something else for the Org structure thing. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 20:44 ` Eric Abrahamsen @ 2017-12-12 20:56 ` Kaushal Modi 0 siblings, 0 replies; 36+ messages in thread From: Kaushal Modi @ 2017-12-12 20:56 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-orgmode, emacs-devel [-- Attachment #1: Type: text/plain, Size: 589 bytes --] On Tue, Dec 12, 2017 at 3:47 PM Eric Abrahamsen <eric@ericabrahamsen.net> wrote: > > Okay, interesting. I agree that "discoverable keymaps" and "action > dispatchers" (whatever Org and Magit do) aren't quite the same thing, > and it would be nice to have both. I guess in the meantime, though, > we're still going to have to use something else for the Org structure > thing. > Correct. That's why I spawned off this "something for future" thread, and did not talk about this in the original thread[1] :) [1]: http://lists.gnu.org/r/emacs-orgmode/2017-12/msg00221.html -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1127 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 14:02 ` Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list) Kaushal Modi 2017-12-12 18:45 ` Key binding popup interface Eric S Fraga 2017-12-12 20:20 ` Eric Abrahamsen @ 2017-12-12 21:01 ` Stefan Monnier 2017-12-12 21:19 ` Kaushal Modi ` (2 more replies) 2 siblings, 3 replies; 36+ messages in thread From: Stefan Monnier @ 2017-12-12 21:01 UTC (permalink / raw) To: emacs-devel; +Cc: emacs-orgmode > Problem statement: Need to have a pretty interface that shows the available > valid key bindings. [...] > Of all those options and more that I've seen out there, hydra.el looks like > the most elegant and *configurable* option. While Hydra might include the feature you're looking for, AFAICT it does something else than what you're looking for. > Can hydra.el be merged into Emacs core, so that all the packages can start > taking advantage of that? I have no opinion on that part, but if a part of Hydra would be useful for other packages, then it'd be good to split it out: for me "Hydra" means "define a Hydra via defhydra or something like that", so if you tell me to use Hydra to "show the available valid key bindings", I wouldn't know where to start. Stefan ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 21:01 ` Stefan Monnier @ 2017-12-12 21:19 ` Kaushal Modi 2017-12-12 21:48 ` Stefan Monnier 2017-12-12 23:51 ` Robert Weiner 2017-12-13 6:52 ` John Wiegley 2 siblings, 1 reply; 36+ messages in thread From: Kaushal Modi @ 2017-12-12 21:19 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-orgmode, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1275 bytes --] On Tue, Dec 12, 2017 at 4:05 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > Problem statement: Need to have a pretty interface that shows the > available > > valid key bindings. > [...] > > Of all those options and more that I've seen out there, hydra.el looks > like > > the most elegant and *configurable* option. > > While Hydra might include the feature you're looking for, AFAICT it does > something else than what you're looking for. > I don't follow "it does something else than what you're looking for". hydra is used to define interfaces to temporary keymaps with well-formatted hints. I have no opinion on that part, but if a part of Hydra would be useful > for other packages, then it'd be good to split it out: for me "Hydra" > means "define a Hydra via defhydra or something like that", so if you > tell me to use Hydra to "show the available valid key bindings", > I wouldn't know where to start. > I meant that use hydra to define such interfaces.. the package authors would need to use hydra to define these interfaces. All the user would need to know is to hit some X binding to get that popup interface. I quickly went though hydra.el.. isn't defhydra mainly what it is? What would you suggest splitting out of that library? -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1953 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 21:19 ` Kaushal Modi @ 2017-12-12 21:48 ` Stefan Monnier 2017-12-13 15:38 ` Kaushal Modi 0 siblings, 1 reply; 36+ messages in thread From: Stefan Monnier @ 2017-12-12 21:48 UTC (permalink / raw) To: emacs-orgmode; +Cc: emacs-devel >> While Hydra might include the feature you're looking for, AFAICT it does >> something else than what you're looking for. > I don't follow "it does something else than what you're looking for". hydra > is used to define interfaces to temporary keymaps with well-formatted hints. I tend to think of Hydra as "bindings that stick around" (to take the wording on the first line of hydra.el), rather than "ways to show available bindings of the current submap". So, yes, I think it does something else (something more) than what I understand you want. And, BTW, if I take a hydra like (defhydra hydra-zoom (global-map "<f6>") "zoom" ("g" text-scale-increase "in") ("l" text-scale-decrease "out")) and I press `f6` I don't get any help in the echo area (nor in the "lv" area). I only get that help after pressing `f6 g` or `f6 l`, so I need some other mechanism to find those "initial" key bindings. So in this respect, I think it does something less than what I understand you'd want. > I quickly went though hydra.el.. isn't defhydra mainly what it is? What > would you suggest splitting out of that library? I don't know enough about it to have a clear opinion on that. Stefan ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 21:48 ` Stefan Monnier @ 2017-12-13 15:38 ` Kaushal Modi 2017-12-13 16:18 ` Stefan Monnier 0 siblings, 1 reply; 36+ messages in thread From: Kaushal Modi @ 2017-12-13 15:38 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-orgmode, emacs-devel [-- Attachment #1: Type: text/plain, Size: 4223 bytes --] On Tue, Dec 12, 2017 at 4:49 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote: > I tend to think of Hydra as "bindings that stick around" (to take the > wording on the first line of hydra.el), rather than "ways to show > available bindings of the current submap". So, yes, I think it does > something else (something more) Well, that's correct .. than what I understand you want. > Though I now think I did a very bad job at constructing that problem statement. But I know for sure that hydra.el fits the bill perfectly (I've been using it ever since Oleh released it). Integrating hydra into emacs with help package developers do these: - Create interfaces for transitional keymaps - The bindings could be sticky or not (can be configured in hydra) - Allow customizing the descriptions of the bindings (@JWiegley as you later suggest which-key, which-key does not allow that.. well it does.. but the user will need to tweak the description, etc.. I see which-end more as a tool only for the end-user. hydra can be used both by package developers and end users). - Pick and choose which bindings to "show" in that interface.. you don't have to show all. The package developer may choose to have duplicate bindings for some function in that keymap, but prefer to show only the preferred binding in the hydra popup (cannot do that in which-key.. it shows *everything*). > And, BTW, if I take a hydra like > > (defhydra hydra-zoom (global-map "<f6>") > "zoom" > ("g" text-scale-increase "in") > ("l" text-scale-decrease "out")) > > and I press `f6` I don't get any help in the echo area (nor in the "lv" > area). I only get that help after pressing `f6 g` or `f6 l`, so I need > some other mechanism to find those "initial" key bindings. > That's because you used Style 1 (as explained in this hydra Wiki: https://github.com/abo-abo/hydra/wiki/Binding-Styles). Use the Style 2 to take care of the issue you stated: (defhydra hydra-zoom () "zoom" ("g" text-scale-increase "in") ("l" text-scale-decrease "out")) (global-set-key (kbd "C-c") 'hydra-zoom/body) In Style 1, you allow the hydra to share the "keymap space" with other bindings not related to that hydra. In Style 2, the hydra takes over the whole "keymap space". In above Style 2 example, the "C-c" space is completely ruled by the hydra-zoom hydra. > So in this respect, I think it does something less than what > I understand you'd want. > No. It does everything that I need to do. But of course it has a lot of features, which might be suitable for different applications. See keys like :pre, :post and more described in https://github.com/abo-abo/hydra/wiki/internals. I can see something like this begin added to smerge.el if and when hydra.el gets merged to the core (See the use of :pre and :post): (defhydra hydra-smerge (:color pink :hint nil :pre (smerge-mode 1) ;; Disable `smerge-mode' when quitting hydra if ;; no merge conflicts remain. :post (smerge-auto-leave)) " ^Move^ ^Keep^ ^Diff^ ^Other^ ^^-----------^^-------------------^^---------------------^^------- _n_ext _b_ase _<_: upper/base _C_ombine _p_rev _u_pper _=_: upper/lower _r_esolve ^^ _l_ower _>_: base/lower _k_ill current ^^ _a_ll _R_efine ^^ _RET_: current _E_diff " ("n" smerge-next) ("p" smerge-prev) ("b" smerge-keep-base) ("u" smerge-keep-upper) ("l" smerge-keep-lower) ("a" smerge-keep-all) ("RET" smerge-keep-current) ("\C-m" smerge-keep-current) ("<" smerge-diff-base-upper) ("=" smerge-diff-upper-lower) (">" smerge-diff-base-lower) ("R" smerge-refine) ("E" smerge-ediff) ("C" smerge-combine-with-next) ("r" smerge-resolve) ("k" smerge-kill-current) ("q" nil "cancel" :color blue)) > > I quickly went though hydra.el.. isn't defhydra mainly what it is? What > > would you suggest splitting out of that library? > > I don't know enough about it to have a clear opinion on that. > OK. Thanks. -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 6504 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-13 15:38 ` Kaushal Modi @ 2017-12-13 16:18 ` Stefan Monnier 0 siblings, 0 replies; 36+ messages in thread From: Stefan Monnier @ 2017-12-13 16:18 UTC (permalink / raw) To: emacs-orgmode; +Cc: emacs-devel > (defhydra hydra-zoom () > "zoom" > ("g" text-scale-increase "in") > ("l" text-scale-decrease "out")) > (global-set-key (kbd "C-c") 'hydra-zoom/body) But now this one suffers from other problems: - `C-h k` does not let me directly find the binding of `C-c g`. - A `C-c a` binding in a lower keymap is now made unavailable. - A `C-c a` binding in a higher keymap now makes this hydra unavailable. > In Style 1, you allow the hydra to share the "keymap space" with other > bindings not related to that hydra. > In Style 2, the hydra takes over the whole "keymap space". In above Style 2 > example, the "C-c" space is completely ruled by the hydra-zoom hydra. I want it all. Don't get me wrong: I fully understand that hydra.el works within the constraints of what Emacs provides and so it has to choose between style 1 or style 2, but if we're talking about integrating this into Emacs, then we should take the opportunity to lift those restrictions. Stefan ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 21:01 ` Stefan Monnier 2017-12-12 21:19 ` Kaushal Modi @ 2017-12-12 23:51 ` Robert Weiner 2017-12-13 15:40 ` Kaushal Modi 2017-12-13 6:52 ` John Wiegley 2 siblings, 1 reply; 36+ messages in thread From: Robert Weiner @ 2017-12-12 23:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-orgmode, emacs-devel [-- Attachment #1: Type: text/plain, Size: 823 bytes --] On Tue, Dec 12, 2017 at 4:01 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > > Can hydra.el be merged into Emacs core, so that all the packages can > start > > taking advantage of that? > > I have no opinion on that part, but if a part of Hydra would be useful > for other packages, then it'd be good to split it out: for me "Hydra" > means "define a Hydra via defhydra or something like that", so if you > tell me to use Hydra to "show the available valid key bindings", > I wouldn't know where to start. > One limitation of hydra right now is that it doesn't interface with the standard way of showing help for key bindings since its keys aren't actually bound but handled via internal hydra event handling. With a bit of thought though, I think it could be integrated well. Bob [-- Attachment #2: Type: text/html, Size: 1752 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 23:51 ` Robert Weiner @ 2017-12-13 15:40 ` Kaushal Modi 2017-12-13 16:25 ` Robert Weiner 0 siblings, 1 reply; 36+ messages in thread From: Kaushal Modi @ 2017-12-13 15:40 UTC (permalink / raw) To: rswgnu; +Cc: Oleh Krehel, emacs-org list, Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 582 bytes --] On Tue, Dec 12, 2017 at 6:51 PM Robert Weiner <rsw@gnu.org> wrote: > > One limitation of hydra right now is that it doesn't interface with the > standard way of showing help for key bindings since its keys aren't > actually bound but handled via internal hydra event handling. With a bit > of thought though, I think it could be integrated well. > I don't follow what the functional limitations are of what you said. How does your concern affect a package author or the end user? Adding @Oleh back to the thread.. hopefully he can weigh in. -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1122 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-13 15:40 ` Kaushal Modi @ 2017-12-13 16:25 ` Robert Weiner 0 siblings, 0 replies; 36+ messages in thread From: Robert Weiner @ 2017-12-13 16:25 UTC (permalink / raw) To: Kaushal Modi; +Cc: Oleh Krehel, emacs-org list, Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1204 bytes --] On Wed, Dec 13, 2017 at 10:40 AM, Kaushal Modi <kaushal.modi@gmail.com> wrote: > On Tue, Dec 12, 2017 at 6:51 PM Robert Weiner <rsw@gnu.org> wrote: > >> >> One limitation of hydra right now is that it doesn't interface with the >> standard way of showing help for key bindings since its keys aren't >> actually bound but handled via internal hydra event handling. With a bit >> of thought though, I think it could be integrated well. >> > > I don't follow what the functional limitations are of what you said. How > does your concern affect a package author or the end user? > C-h k shows the documentation for a key binding in a help buffer rather than just a laid out summary of all the keys in a particular hydra map. C-h k is important to know the details of what individual keys do, so hydra needs a way of integrating with standard key documentation lookup capabilities if it gets integrated with core Emacs, which I would like to see. Personally, I also think the red, blue, etc. color notation should change to something more descriptive of what they do and then the particular colors associated could be customized to suit any particular visual theme. Bob [-- Attachment #2: Type: text/html, Size: 2985 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-12 21:01 ` Stefan Monnier 2017-12-12 21:19 ` Kaushal Modi 2017-12-12 23:51 ` Robert Weiner @ 2017-12-13 6:52 ` John Wiegley 2017-12-13 15:43 ` Kaushal Modi 2 siblings, 1 reply; 36+ messages in thread From: John Wiegley @ 2017-12-13 6:52 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-orgmode, emacs-devel >>>>> "SM" == Stefan Monnier <monnier@iro.umontreal.ca> writes: SM> I have no opinion on that part, but if a part of Hydra would be useful for SM> other packages, then it'd be good to split it out: for me "Hydra" means SM> "define a Hydra via defhydra or something like that", so if you tell me to SM> use Hydra to "show the available valid key bindings", I wouldn't know SM> where to start. Plus, there are other, less intrusive way to achieve "show the available valid key bindings", such as the which-key package. I think one area where Hydras come into their own is that once you have the Hydra active, it stays active, allowing you to chain together many single- letter commands. For example, you could have a hydra for "large-scale syntactic structures", where repeated uses of n/p are mapped to what C-c C-n and C-c C-p usually do in modes like cc-mode. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Key binding popup interface 2017-12-13 6:52 ` John Wiegley @ 2017-12-13 15:43 ` Kaushal Modi 0 siblings, 0 replies; 36+ messages in thread From: Kaushal Modi @ 2017-12-13 15:43 UTC (permalink / raw) To: Stefan Monnier, emacs-devel, emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 818 bytes --] On Wed, Dec 13, 2017 at 1:53 AM John Wiegley <johnw@gnu.org> wrote: > Plus, there are other, less intrusive way to achieve "show the available > valid > key bindings", such as the which-key package. > As I mentioned in a recent response to Stefan in this thread, I did a poor job with that problem statement.. I don't want to *just* show the available bindings. I think one area where Hydras come into their own is that once you have the > Hydra active, it stays active, allowing you to chain together many single- > letter commands. > That's correct. It's up to the package author as to how much of hydra features they want to pack into their package's hydras. hydra is not *just* for showing available keys and/or *just* for chaining many single letter commands. It's much more, in a good way. -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1383 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-12 13:49 ` Rasmus 2017-12-12 14:02 ` Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list) Kaushal Modi @ 2017-12-13 0:45 ` Eric Abrahamsen 2017-12-14 9:06 ` Rasmus 1 sibling, 1 reply; 36+ messages in thread From: Eric Abrahamsen @ 2017-12-13 0:45 UTC (permalink / raw) To: emacs-orgmode Rasmus <rasmus@gmx.us> writes: > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: > >> Hello, >> >> Rasmus <rasmus@gmx.us> writes: >> >>> Nicolas, are there any public interfaces to make ox export like >>> interfaces? >> >> No, there isn't. However, Org provides `org-mks'. > > Good point. It isn’t quite as nice as the export dispatcher. Let’s wait > and see what Eric prefers. I don't have to own this! I don't have a strong feeling about it, and left to my own devices would just keep the single-character keys. But I see why people would want more/longer keys, and better discoverability. The main desires are: 1. String keys of arbitrary length. 2. Discoverability: either a window of choices pops up automatically, or you can do it with TAB, etc. 3. Ideally, you don't have to hit an extra key to finish. Given that, it seems to me that `org-mks' is just fine. It doesn't do as much as the export dispatcher, but I don't see that it needs to. The only downside is that it might make the choices a bit harder to customize, as the table argument is more fiddly. But maybe not a big deal. Eric ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-13 0:45 ` Poll: new keybinding for org-insert-structure-template? Eric Abrahamsen @ 2017-12-14 9:06 ` Rasmus 2017-12-14 21:19 ` Eric Abrahamsen 0 siblings, 1 reply; 36+ messages in thread From: Rasmus @ 2017-12-14 9:06 UTC (permalink / raw) To: emacs-orgmode Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Rasmus <rasmus@gmx.us> writes: > >> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: >> >>> Hello, >>> >>> Rasmus <rasmus@gmx.us> writes: >>> >>>> Nicolas, are there any public interfaces to make ox export like >>>> interfaces? >>> >>> No, there isn't. However, Org provides `org-mks'. >> >> Good point. It isn’t quite as nice as the export dispatcher. Let’s wait >> and see what Eric prefers. > > I don't have to own this! I don't have a strong feeling about it, and > left to my own devices would just keep the single-character keys. It’s pretty nice and quick with only one character. > But I see why people would want more/longer keys, and better > discoverability. Discoverability is nice to have, but it’s a secondary issue. > The main desires are: > > 1. String keys of arbitrary length. > 2. Discoverability: either a window of choices pops up automatically, or > you can do it with TAB, etc. > 3. Ideally, you don't have to hit an extra key to finish. > > Given that, it seems to me that `org-mks' is just fine. It doesn't do as > much as the export dispatcher, but I don't see that it needs to. It doesn’t seem to offer a way to distinguish between a single "a" and "ab". (org-mks '(("a" "a.. templates") ("a" "export ascii" "") ("ab" "abstract" "") ("l" "latex" "")) "Select a template" "Template key: " '(("q" "Abort"))) Perhaps the best way would be to automatically reserve upper case letters for blocks with keys longer than one character, although that seems a bit arbitrary. (org-mks '(("A" "a.. templates") ("a" "export ascii" "") ("Ab" "abstract" "") ("l" "latex" "")) "Select a template" "Template key: " '(("q" "Abort"))) Rasmus -- And I faced endless streams of vendor-approved Ikea furniture. . . ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-14 9:06 ` Rasmus @ 2017-12-14 21:19 ` Eric Abrahamsen 2017-12-15 11:22 ` Rasmus 0 siblings, 1 reply; 36+ messages in thread From: Eric Abrahamsen @ 2017-12-14 21:19 UTC (permalink / raw) To: emacs-orgmode Rasmus <rasmus@gmx.us> writes: > Eric Abrahamsen <eric@ericabrahamsen.net> writes: > >> Rasmus <rasmus@gmx.us> writes: >> >>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: >>> >>>> Hello, >>>> >>>> Rasmus <rasmus@gmx.us> writes: >>>> >>>>> Nicolas, are there any public interfaces to make ox export like >>>>> interfaces? >>>> >>>> No, there isn't. However, Org provides `org-mks'. >>> >>> Good point. It isn’t quite as nice as the export dispatcher. Let’s wait >>> and see what Eric prefers. >> >> I don't have to own this! I don't have a strong feeling about it, and >> left to my own devices would just keep the single-character keys. > > It’s pretty nice and quick with only one character. > >> But I see why people would want more/longer keys, and better >> discoverability. > > Discoverability is nice to have, but it’s a secondary issue. > > >> The main desires are: >> >> 1. String keys of arbitrary length. >> 2. Discoverability: either a window of choices pops up automatically, or >> you can do it with TAB, etc. >> 3. Ideally, you don't have to hit an extra key to finish. >> >> Given that, it seems to me that `org-mks' is just fine. It doesn't do as >> much as the export dispatcher, but I don't see that it needs to. > > It doesn’t seem to offer a way to distinguish between a single "a" and > "ab". > > (org-mks '(("a" "a.. templates") > ("a" "export ascii" "") > ("ab" "abstract" "") > ("l" "latex" "")) > "Select a template" > "Template key: " > '(("q" "Abort"))) > > Perhaps the best way would be to automatically reserve upper case letters > for blocks with keys longer than one character, although that seems a bit > arbitrary. > > (org-mks '(("A" "a.. templates") > ("a" "export ascii" "") > ("Ab" "abstract" "") > ("l" "latex" "")) > "Select a template" > "Template key: " > '(("q" "Abort"))) Right, you can't have a string act as both a "sub-menu dispatcher" and a menu item at the same time. I don't see that it's a big deal, though. For the default value, at least, it's pretty clear how we would arrange the values: SRC and EXPORT need sub-menus, and everything else doesn't. Ie: '(("s" "Source Code") ("se" "Elisp" "src elisp") ("sp" "Python" "src python") ...etc ("e" "Export Block") ("eh" "HTML" "export html") ("el" "LaTeX" "export latex") ...etc ("v" "Verbatim" "verbatim") ("q" "Quote" "quote") ("E" "Example" "example") ...etc ) That's not so bad, is it? Eric ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-14 21:19 ` Eric Abrahamsen @ 2017-12-15 11:22 ` Rasmus 2017-12-15 12:59 ` Kaushal Modi 0 siblings, 1 reply; 36+ messages in thread From: Rasmus @ 2017-12-15 11:22 UTC (permalink / raw) To: emacs-orgmode Eric Abrahamsen <eric@ericabrahamsen.net> writes: > That's not so bad, is it? The only way it’s "bad" is in the sense it limits the flexibility of snippets, like "<s". As you point out, if I add "<sr" as an "src R" block I can no longer have "<s" as plain "src" block. Unless, the meaning of key in org-structure-template-alist is handled differently in the case of snippet expansion and insertion via org-insert-structure-template. Rasmus -- In theory, practice and theory are the same. In practice they are not ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-15 11:22 ` Rasmus @ 2017-12-15 12:59 ` Kaushal Modi 2017-12-15 13:15 ` Rasmus 0 siblings, 1 reply; 36+ messages in thread From: Kaushal Modi @ 2017-12-15 12:59 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 665 bytes --] On Fri, Dec 15, 2017 at 6:23 AM Rasmus <rasmus@gmx.us> wrote: > The only way it’s "bad" is in the sense it limits the flexibility of > snippets, like "<s". As you point out, if I add "<sr" as an "src R" block > I can no longer have "<s" as plain "src" block. May be have "<ss" insert plain source block, "<ee", plain export block? I missed this in the original conversation, but in the cases where plain source/export blocks are inserted, does the point move to where the language/backend needs to be typed? i.e. you insert a plain source block and point ends up where "|" is shown below: #+BEGIN_SRC | #+END_SRC -- Kaushal Modi [-- Attachment #2: Type: text/html, Size: 1230 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-15 12:59 ` Kaushal Modi @ 2017-12-15 13:15 ` Rasmus 2017-12-15 17:40 ` Eric Abrahamsen 0 siblings, 1 reply; 36+ messages in thread From: Rasmus @ 2017-12-15 13:15 UTC (permalink / raw) To: kaushal.modi; +Cc: emacs-orgmode Kaushal Modi <kaushal.modi@gmail.com> writes: > On Fri, Dec 15, 2017 at 6:23 AM Rasmus <rasmus@gmx.us> wrote: > >> The only way it’s "bad" is in the sense it limits the flexibility of >> snippets, like "<s". As you point out, if I add "<sr" as an "src R" block >> I can no longer have "<s" as plain "src" block. > > > May be have "<ss" insert plain source block, "<ee", plain export block? I wouldn’t really like that. > I missed this in the original conversation, but in the cases where plain > source/export blocks are inserted, does the point move to where the > language/backend needs to be typed? When using Org Tempo an extra space is always inserted. It probably should only do it with blocks that support arguments, actually. ATM I don’t think spaces are inserted when using ‘org-insert-structure-template’, but I they’ll probably be consistent eventually. Rasmus -- To err is human. To screw up 10⁶ times per second, you need a computer ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-15 13:15 ` Rasmus @ 2017-12-15 17:40 ` Eric Abrahamsen 2017-12-18 18:23 ` Eric Abrahamsen 0 siblings, 1 reply; 36+ messages in thread From: Eric Abrahamsen @ 2017-12-15 17:40 UTC (permalink / raw) To: emacs-orgmode Rasmus <rasmus@gmx.us> writes: > Kaushal Modi <kaushal.modi@gmail.com> writes: > >> On Fri, Dec 15, 2017 at 6:23 AM Rasmus <rasmus@gmx.us> wrote: >> >>> The only way it’s "bad" is in the sense it limits the flexibility of >>> snippets, like "<s". As you point out, if I add "<sr" as an "src R" block >>> I can no longer have "<s" as plain "src" block. I don't see any way around that. Any system that allows string keys of arbitrary length is going to run into that problem. >> May be have "<ss" insert plain source block, "<ee", plain export block? > > I wouldn’t really like that. > >> I missed this in the original conversation, but in the cases where plain >> source/export blocks are inserted, does the point move to where the >> language/backend needs to be typed? > > When using Org Tempo an extra space is always inserted. It probably > should only do it with blocks that support arguments, actually. ATM I > don’t think spaces are inserted when using > ‘org-insert-structure-template’, but I they’ll probably be consistent > eventually. I think the idea was that for src and export blocks, where you're likely to be adding additional parameters, point is moved to the end of the #+begin line. Actually I think that's what happens now. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-15 17:40 ` Eric Abrahamsen @ 2017-12-18 18:23 ` Eric Abrahamsen 2017-12-19 11:40 ` Rasmus 0 siblings, 1 reply; 36+ messages in thread From: Eric Abrahamsen @ 2017-12-18 18:23 UTC (permalink / raw) To: emacs-orgmode Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Rasmus <rasmus@gmx.us> writes: > >> Kaushal Modi <kaushal.modi@gmail.com> writes: >> >>> On Fri, Dec 15, 2017 at 6:23 AM Rasmus <rasmus@gmx.us> wrote: >>> >>>> The only way it’s "bad" is in the sense it limits the flexibility of >>>> snippets, like "<s". As you point out, if I add "<sr" as an "src R" block >>>> I can no longer have "<s" as plain "src" block. > > I don't see any way around that. Any system that allows string keys of > arbitrary length is going to run into that problem. One possible fix, a bit arbitrary: in the default value, provide <TAB> as an artificial "stop key" in the sub-menus. So "s" starts the "source code" sub-menu, and a <TAB> after that simply inserts "#+begin_src", and leaves point after that. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-18 18:23 ` Eric Abrahamsen @ 2017-12-19 11:40 ` Rasmus 2017-12-20 16:36 ` Eric Abrahamsen 0 siblings, 1 reply; 36+ messages in thread From: Rasmus @ 2017-12-19 11:40 UTC (permalink / raw) To: emacs-orgmode Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Eric Abrahamsen <eric@ericabrahamsen.net> writes: > >> Rasmus <rasmus@gmx.us> writes: >> >>> Kaushal Modi <kaushal.modi@gmail.com> writes: >>> >>>> On Fri, Dec 15, 2017 at 6:23 AM Rasmus <rasmus@gmx.us> wrote: >>>> >>>>> The only way it’s "bad" is in the sense it limits the flexibility of >>>>> snippets, like "<s". As you point out, if I add "<sr" as an "src R" block >>>>> I can no longer have "<s" as plain "src" block. >> >> I don't see any way around that. Any system that allows string keys of >> arbitrary length is going to run into that problem. > > One possible fix, a bit arbitrary: in the default value, provide <TAB> > as an artificial "stop key" in the sub-menus. So "s" starts the "source > code" sub-menu, and a <TAB> after that simply inserts "#+begin_src", and > leaves point after that. Yeah, I tried to suggest that earlier (unless I didn’t say it), but I might not have expressed the idea in an understandable manner :) I think that would be the best approach, but there’s no infrastructure that I know of that does this ATM (but I haven’t had a lot of time lately, so my knowledge on this issue is limited!). Rasmus -- 9000! ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-19 11:40 ` Rasmus @ 2017-12-20 16:36 ` Eric Abrahamsen 2017-12-20 16:48 ` Eric Abrahamsen 0 siblings, 1 reply; 36+ messages in thread From: Eric Abrahamsen @ 2017-12-20 16:36 UTC (permalink / raw) To: emacs-orgmode Rasmus <rasmus@gmx.us> writes: > Eric Abrahamsen <eric@ericabrahamsen.net> writes: > >> Eric Abrahamsen <eric@ericabrahamsen.net> writes: >> >>> Rasmus <rasmus@gmx.us> writes: >>> >>>> Kaushal Modi <kaushal.modi@gmail.com> writes: >>>> >>>>> On Fri, Dec 15, 2017 at 6:23 AM Rasmus <rasmus@gmx.us> wrote: >>>>> >>>>>> The only way it’s "bad" is in the sense it limits the flexibility of >>>>>> snippets, like "<s". As you point out, if I add "<sr" as an "src R" block >>>>>> I can no longer have "<s" as plain "src" block. >>> >>> I don't see any way around that. Any system that allows string keys of >>> arbitrary length is going to run into that problem. >> >> One possible fix, a bit arbitrary: in the default value, provide <TAB> >> as an artificial "stop key" in the sub-menus. So "s" starts the "source >> code" sub-menu, and a <TAB> after that simply inserts "#+begin_src", and >> leaves point after that. > > Yeah, I tried to suggest that earlier (unless I didn’t say it), but I > might not have expressed the idea in an understandable manner :) Maybe I missed it! > I think that would be the best approach, but there’s no infrastructure > that I know of that does this ATM (but I haven’t had a lot of time lately, > so my knowledge on this issue is limited!). Can't we do this with tempo? It will have to be "handmade", not automatic, but: '(("s" "Source Code") ("se" "Elisp" "src elisp") ("sp" "Python" "src python") ("TAB" "Empty" "src ") ...etc ("e" "Export Block") ("eh" "HTML" "export html") ("el" "LaTeX" "export latex") ("TAB" "Empty" "export ") ...etc ("v" "Verbatim" "verbatim") ("q" "Quote" "quote") ("E" "Example" "example") ...etc ) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-20 16:36 ` Eric Abrahamsen @ 2017-12-20 16:48 ` Eric Abrahamsen 2017-12-21 9:16 ` Rasmus 0 siblings, 1 reply; 36+ messages in thread From: Eric Abrahamsen @ 2017-12-20 16:48 UTC (permalink / raw) To: emacs-orgmode Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Rasmus <rasmus@gmx.us> writes: > >> Eric Abrahamsen <eric@ericabrahamsen.net> writes: >> >>> Eric Abrahamsen <eric@ericabrahamsen.net> writes: >>> >>>> Rasmus <rasmus@gmx.us> writes: >>>> >>>>> Kaushal Modi <kaushal.modi@gmail.com> writes: >>>>> >>>>>> On Fri, Dec 15, 2017 at 6:23 AM Rasmus <rasmus@gmx.us> wrote: >>>>>> >>>>>>> The only way it’s "bad" is in the sense it limits the flexibility of >>>>>>> snippets, like "<s". As you point out, if I add "<sr" as an "src R" block >>>>>>> I can no longer have "<s" as plain "src" block. >>>> >>>> I don't see any way around that. Any system that allows string keys of >>>> arbitrary length is going to run into that problem. >>> >>> One possible fix, a bit arbitrary: in the default value, provide <TAB> >>> as an artificial "stop key" in the sub-menus. So "s" starts the "source >>> code" sub-menu, and a <TAB> after that simply inserts "#+begin_src", and >>> leaves point after that. >> >> Yeah, I tried to suggest that earlier (unless I didn’t say it), but I >> might not have expressed the idea in an understandable manner :) > > Maybe I missed it! > >> I think that would be the best approach, but there’s no infrastructure >> that I know of that does this ATM (but I haven’t had a lot of time lately, >> so my knowledge on this issue is limited!). > > Can't we do this with tempo? It will have to be "handmade", not > automatic, but: > > '(("s" "Source Code") > ("se" "Elisp" "src elisp") > ("sp" "Python" "src python") > ("TAB" "Empty" "src ") > ...etc > ("e" "Export Block") > ("eh" "HTML" "export html") > ("el" "LaTeX" "export latex") > ("TAB" "Empty" "export ") > ...etc > ("v" "Verbatim" "verbatim") > ("q" "Quote" "quote") > ("E" "Example" "example") > ...etc > ) Ahem, should have actually tried that first: (org-mks '(("s" "Source Code") ("se" "Elisp" "src elisp") ("sp" "Python" "src python") ("s\t" "Empty" "src ") ("e" "Export Block") ("eh" "HTML" "export html") ("el" "LaTeX" "export latex") ("s\t" "Empty" "export ") ("v" "Verbatim" "verbatim") ("q" "Quote" "quote") ("E" "Example" "example")) "Insert Block" "Block: ") It's a bit ugly, but it works... ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Poll: new keybinding for org-insert-structure-template? 2017-12-20 16:48 ` Eric Abrahamsen @ 2017-12-21 9:16 ` Rasmus 0 siblings, 0 replies; 36+ messages in thread From: Rasmus @ 2017-12-21 9:16 UTC (permalink / raw) To: emacs-orgmode Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Eric Abrahamsen <eric@ericabrahamsen.net> writes: > >> Rasmus <rasmus@gmx.us> writes: >> >>> Eric Abrahamsen <eric@ericabrahamsen.net> writes: >>> >>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes: >>>> >>>>> Rasmus <rasmus@gmx.us> writes: >>>>> >>>>>> Kaushal Modi <kaushal.modi@gmail.com> writes: >>>>>> >>>>>>> On Fri, Dec 15, 2017 at 6:23 AM Rasmus <rasmus@gmx.us> wrote: >>>>>>> >>>>>>>> The only way it’s "bad" is in the sense it limits the flexibility of >>>>>>>> snippets, like "<s". As you point out, if I add "<sr" as an "src R" block >>>>>>>> I can no longer have "<s" as plain "src" block. >>>>> >>>>> I don't see any way around that. Any system that allows string keys of >>>>> arbitrary length is going to run into that problem. >>>> >>>> One possible fix, a bit arbitrary: in the default value, provide <TAB> >>>> as an artificial "stop key" in the sub-menus. So "s" starts the "source >>>> code" sub-menu, and a <TAB> after that simply inserts "#+begin_src", and >>>> leaves point after that. >>> >>> Yeah, I tried to suggest that earlier (unless I didn’t say it), but I >>> might not have expressed the idea in an understandable manner :) >> >> Maybe I missed it! >> >>> I think that would be the best approach, but there’s no infrastructure >>> that I know of that does this ATM (but I haven’t had a lot of time lately, >>> so my knowledge on this issue is limited!). >> >> Can't we do this with tempo? It will have to be "handmade", not >> automatic, but: >> >> '(("s" "Source Code") >> ("se" "Elisp" "src elisp") >> ("sp" "Python" "src python") >> ("TAB" "Empty" "src ") >> ...etc >> ("e" "Export Block") >> ("eh" "HTML" "export html") >> ("el" "LaTeX" "export latex") >> ("TAB" "Empty" "export ") >> ...etc >> ("v" "Verbatim" "verbatim") >> ("q" "Quote" "quote") >> ("E" "Example" "example") >> ...etc >> ) > > Ahem, should have actually tried that first: > > (org-mks > '(("s" "Source Code") > ("se" "Elisp" "src elisp") > ("sp" "Python" "src python") > ("s\t" "Empty" "src ") > ("e" "Export Block") > ("eh" "HTML" "export html") > ("el" "LaTeX" "export latex") > ("s\t" "Empty" "export ") > ("v" "Verbatim" "verbatim") > ("q" "Quote" "quote") > ("E" "Example" "example")) > "Insert Block" "Block: ") > > It's a bit ugly, but it works... Great find; I didn’t realize we can use tab here! I’ll try to build the mks list automatically. It will be a bit annoying, as we’ll have to figure out valid keys for things like "prop". Rasmus -- Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2017-12-21 9:17 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-12-10 0:23 Poll: new keybinding for org-insert-structure-template? Eric Abrahamsen 2017-12-10 11:26 ` Rasmus 2017-12-10 19:37 ` Eric Abrahamsen 2017-12-12 7:48 ` Rasmus 2017-12-12 7:55 ` Nicolas Goaziou 2017-12-12 13:49 ` Rasmus 2017-12-12 14:02 ` Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list) Kaushal Modi 2017-12-12 18:45 ` Key binding popup interface Eric S Fraga 2017-12-12 18:56 ` Kaushal Modi 2017-12-12 19:53 ` Alan E. Davis 2017-12-12 20:20 ` Eric Abrahamsen 2017-12-12 20:33 ` Kaushal Modi 2017-12-12 20:44 ` Eric Abrahamsen 2017-12-12 20:56 ` Kaushal Modi 2017-12-12 21:01 ` Stefan Monnier 2017-12-12 21:19 ` Kaushal Modi 2017-12-12 21:48 ` Stefan Monnier 2017-12-13 15:38 ` Kaushal Modi 2017-12-13 16:18 ` Stefan Monnier 2017-12-12 23:51 ` Robert Weiner 2017-12-13 15:40 ` Kaushal Modi 2017-12-13 16:25 ` Robert Weiner 2017-12-13 6:52 ` John Wiegley 2017-12-13 15:43 ` Kaushal Modi 2017-12-13 0:45 ` Poll: new keybinding for org-insert-structure-template? Eric Abrahamsen 2017-12-14 9:06 ` Rasmus 2017-12-14 21:19 ` Eric Abrahamsen 2017-12-15 11:22 ` Rasmus 2017-12-15 12:59 ` Kaushal Modi 2017-12-15 13:15 ` Rasmus 2017-12-15 17:40 ` Eric Abrahamsen 2017-12-18 18:23 ` Eric Abrahamsen 2017-12-19 11:40 ` Rasmus 2017-12-20 16:36 ` Eric Abrahamsen 2017-12-20 16:48 ` Eric Abrahamsen 2017-12-21 9:16 ` Rasmus
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.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).
![[-- Attachment #2: image.png --] [-- Type: image/png, Size: 20877 bytes --]](../../CAFyQvY30trCsCP0gcpiKJ2WenSvfDuKDwpF2z3LaUcf-EymVMw@mail.gmail.com/2-image.png){kind=link}