Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list)

Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list)

[Kaushal Modi]

[-- 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 --]

Re: Key binding popup interface

[Eric S Fraga]

[-- 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 --]

Re: Key binding popup interface

[Kaushal Modi]

[-- 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 --]

Re: Key binding popup interface

[Alan E. Davis]

[-- 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 --]

Re: Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list)

[Charles A. Roelli]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 12 Dec 2017 14:02:29 +0000
> 
> Problem statement: Need to have a pretty interface that shows the available valid key bindings. 

Why not use a simple menu?  It seems to be the standard way to show a
list of commands with their available bindings.  If it doesn't fit the
bill, maybe it can be improved.

Re: Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list)

[Kaushal Modi]

[-- Attachment #1.1: Type: text/plain, Size: 1258 bytes --]

On Tue, Dec 12, 2017 at 3:06 PM Charles A. Roelli <charles@aurox.ch> wrote:

> > From: Kaushal Modi <kaushal.modi@gmail.com>
> > Date: Tue, 12 Dec 2017 14:02:29 +0000
> >
> > Problem statement: Need to have a pretty interface that shows the
> available valid key bindings.
>
> Why not use a simple menu?  It seems to be the standard way to show a
> list of commands with their available bindings.  If it doesn't fit the
> bill, maybe it can be improved.
>

Do you mean a graphical menu from the menu bar or the menu shown by mouse
clicks. If so, I am using none of those.

Also I should have made a better problem statement: "Need to have a pretty
interface that is *configurable* and shows the key bindings for that action.

For instance, I have a hydra to insert different Org blocks in org-mode,
and looks like this:

[image: image.png]
The idea is to press a binding, and then a contextual menu pops up with a
list of next valid key that can be pressed (and this does not necessarily
list *all* the bound keys.. that's one place where it's different from
another package: which-key).

I wrote a reply with bit more information about hydra earlier today in this
thread[1].

[1]: http://lists.gnu.org/r/emacs-devel/2017-12/msg00383.html

-- 

Kaushal Modi

[-- Attachment #1.2: Type: text/html, Size: 2031 bytes --]

[-- Attachment #2: image.png --]
[-- Type: image/png, Size: 13667 bytes --]

Re: Key binding popup interface

[Stefan Monnier]

> For instance, I have a hydra to insert different Org blocks in org-mode,
> and looks like this:
> [image: image.png]

[ Hmm... Gnus here doesn't seem to provide any way for me to see
  this image.  ]

> The idea is to press a binding, and then a contextual menu pops up with a
> list of next valid key that can be pressed (and this does not necessarily
> list *all* the bound keys.. that's one place where it's different from
> another package: which-key).

This sounds a bit like the primitive "hierarkey" feature which I used in
PCL-CVS.  Basically there I defined a sub-keymap bound to `d` with
bindings like:

       (?= . ("diff" . cvs-mode-diff))
       (?2 . ("other" . cvs-mode-diff-other))
       (?d . ("diff"  . cvs-mode-diff))
       (?v . ("vendor"  . cvs-mode-diff))
       ...

so after hitting `d` Emacs shows in the each area something like
"Diff: vendor, diff, = = diff, 2 = other, ...".

This is a very old feature implemented in the C code (src/keyboard.c)
and very little used.

It would be good to replace it with a more powerful feature implemented
in Elisp and used more widely.


        Stefan

Re: Key binding popup interface

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

On Tue, Dec 12, 2017 at 4:19 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > For instance, I have a hydra to insert different Org blocks in org-mode,
> > and looks like this:
> > [image: image.png]
>
> [ Hmm... Gnus here doesn't seem to provide any way for me to see
>   this image.  ]
>

Sorry about that.. don't those images show up as attachments? They show up
on the mailing list page fine. Here are 2 messages where I pasted images in
this thread:

- http://lists.gnu.org/r/emacs-devel/2017-12/msg00392.html
- http://lists.gnu.org/r/emacs-devel/2017-12/msg00395.html

This sounds a bit like the primitive "hierarkey" feature which I used in
> PCL-CVS.  Basically there I defined a sub-keymap bound to `d` with
> bindings like:
>
>        (?= . ("diff" . cvs-mode-diff))
>        (?2 . ("other" . cvs-mode-diff-other))
>        (?d . ("diff"  . cvs-mode-diff))
>        (?v . ("vendor"  . cvs-mode-diff))
>        ...
>
> so after hitting `d` Emacs shows in the each area something like
> "Diff: vendor, diff, = = diff, 2 = other, ...".
>

I had not heard of that!

This is a very old feature implemented in the C code (src/keyboard.c)
> and very little used.
>
> It would be good to replace it with a more powerful feature implemented
> in Elisp and used more widely.
>

That's a +1 for hydra? :)

You can check out more examples of hydra on its Wiki[1]. I have quite a few
hydra examples in my emacs config too[2].

[1]: https://github.com/abo-abo/hydra/wiki/Emacs
[2]: https://github.com/kaushalmodi/.emacs.d/search?l=Emacs+Lisp&q=defhydra
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2846 bytes --]

Re: Key binding popup interface

[Michael Heerdegen]

Kaushal Modi <kaushal.modi@gmail.com> writes:

>  [ Hmm... Gnus here doesn't seem to provide any way for me to see
>    this image.  ]
>
> Sorry about that.. don't those images show up as attachments? They
> show up on the mailing list page fine.

Works here, I see an inline image with my Gnus.


Michael.

Re: Key binding popup interface (Was: Re: Poll: new keybinding for org-insert-structure-template on org mode list)

[Charles A. Roelli]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Tue, 12 Dec 2017 20:20:42 +0000
> 
>  > From: Kaushal Modi <kaushal.modi@gmail.com>
>  > Date: Tue, 12 Dec 2017 14:02:29 +0000
>  >
>  > Problem statement: Need to have a pretty interface that shows the available valid key bindings.
> 
>  Why not use a simple menu? It seems to be the standard way to show a
>  list of commands with their available bindings. If it doesn't fit the
>  bill, maybe it can be improved.
> 
> Do you mean a graphical menu from the menu bar or the menu shown by mouse clicks. If so, I am using none of those.

Graphical menu and mouse are optional.  Try M-x tmm-menubar RET.

Re: Key binding popup interface

[Eric Abrahamsen]

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.

Re: Key binding popup interface

[Kaushal Modi]

[-- 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 --]

Re: Key binding popup interface

[Eric Abrahamsen]

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.

Re: Key binding popup interface

[Kaushal Modi]

[-- 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 --]

Re: Key binding popup interface

[Stefan Monnier]

> 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

Re: Key binding popup interface

[Kaushal Modi]

[-- 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 --]

Re: Key binding popup interface

[Stefan Monnier]

>> 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

Re: Key binding popup interface

[Kaushal Modi]

[-- 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 --]

Re: Key binding popup interface

[Stefan Monnier]

> (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

Re: Key binding popup interface

[Robert Weiner]

[-- 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 --]

Re: Key binding popup interface

[Kaushal Modi]

[-- 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 --]

Re: Key binding popup interface

[Robert Weiner]

[-- 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 --]

Re: Key binding popup interface

[John Wiegley]

>>>>> "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

Re: Key binding popup interface

[Kaushal Modi]

[-- 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 --]