Should `amaranth` be a "color"?

[ffevotte]

When playing with amaranth hydras, I got struck by what looks to my like an inconsistency in hydra's API:

• amaranth (or rather, the concept of a hydra that is only killed by predefined keys) is a property related to the hydra's body. It doesn't make sense to inherit this from body to heads.
• blue/red (or, rather, the concepts of hydra heads that get the hydra killed or not) are properties related to hydra heads.
• both are orthogonal, i.e. the fact that the body is amaranth or not doesn't necessarily imply that heads should be blue or red.

Therefore, I would suggest:

1. that different property names be used for these different concepts (instead of the common :color property), so that heads can always inherit from a default value from the body,
2. optionally, that more meaningful/mnemonic names be chosen for the properties. I know this specific question has already been raised in the blog post introducing colorful hydrae, but I'm raising it again here in case the change related to amaranth hydras would be reason enough to justify a move.

As always, I love hydrae as they are and all these are just suggestions. Please feel free to ignore them.

---

Just a bit of context here to justify my position:

Like many endless parentheses fans, I have defined a toggle map and a launcher map. Since I don't use them all the time, I use guide-key to help me remember the bindings in them.

I then realized that I could convert these keymaps to hydras with all blue heads. Taking advantage of the inheritance between hydra body and heads greatly reduces the burden of defining this:

(global-set-key
 (kbd "C-x t")
 (defhydra hydra/toggle (:color blue)
   ("c" column-number-mode)
   ("d" toggle-debug-on-error)
   ("f" auto-fill-mode)
   ...))

A bit later I realized that I could improve this by making the hydra amaranth: the toggle/launcher maps would then be error-free. But by doing this, I can't use color inheritance any more, which is a pity:

(global-set-key
 (kbd "C-x t")
 (defhydra hydra/toggle (:color amaranth)
   ("c" column-number-mode :color blue)
   ("d" toggle-debug-on-error :color blue)
   ("f" auto-fill-mode :color blue)
   ...))

[abo-abo]

I get your point, I saw the inconsistency myself as I was introducing amaranth. My point with the colors was to introduce archetypes that were best suited for a particular task:

• red for a whole lot of (almost) mode-free repeating
• blue for a better define-key
• amaranth for defining modal stuff

My feeling was (and still is), that it's best to have a few (three so far) archetypes that combine property choices, rather than e.g. 4 (fake) orthogonal binary properties that don't actually combine into 16 different groups, but rather like 5 out of 16 combinations can possibly work.

I think it's best to just try to add more features and see what works and what doesn't work, rather than rewriting the interface at this point.

Although, if there was a :noquit key, nil by default:

• :color red :noquit nil => plain hydra
• :color red :noquit t => amaranth hydra
• :color blue :noquit nil => define-key hydra
• :color blue :noquit t => what-you-want hydra

The first three things definitely work. Let me try the what-you-want hydra for a while. If it works, maybe it's a good idea to add :noquit.

On the other hand, if I add :noquit now, and :color green later, I'll have to make sure that both :color green :noquit nil and :color green :noquit t make sense, so I'd be placing a constraint on the interface.

[ffevotte]

Thanks for your answer.

My feeling was (and still is), that it's best to have a few (three so far) archetypes that combine property choices, rather than e.g. 4 (fake) orthogonal binary properties that don't actually combine into 16 different groups, but rather like 5 out of 16 combinations can possibly work.

I think I begin to understand more clearly. I would say my point is that strong consistency would allow easier coding of the inner workings (a few properties having limited effect on a localized portion of the code). While your point seems to be more user-oriented: if a given combination plainly doesn't work, just don't expose it so users can't get surprised.

I would say both approaches have pros and cons, but at least I understand your standpoint now.

On the other hand, if I add :noquit now, and :color green later, I'll have to make sure that both :color green :noquit nil and :color green :noquit t make sense, so I'd be placing a constraint on the interface.

Yep. that's never an easy choice: either you rewrite the interface now and place constraints for the future. Or you don't, and if it is eventually needed, an interface change will be more difficult in the future.

In any case, either solution is just fine, and no unfixable situation can occur, so I'm confident hydra will remain good and useful either way!

[abo-abo]

In any case, either solution is just fine

I went with the solution of using colors to represent a combination of properties. So far, there are 5/8 for three "binary" properties. It can easily be changed to binary properties in the future if the need should arise.

[ffevotte]

Very nice, thanks a lot!