Proposal for more congruent default shortcuts for directional Paredit commands: e.g. Slurp/Barf and Backward-Down-Sexp/Forward-Up-Sexp

[skylize]

Paraedit shortcuts for slurping and barfing are poorly coordinated with each other, especially on Linux.

Currently (on Linux), forward movements use Ctrl-Alt with the side-by-side . and , for choosing slurp or barf. In both cases the inner monologue is "xxx Forward", yet we use the right-sided option . for slurp and the left-sided option , for barf.

That doesn't seem terrible on it's own. But meanwhile, backwards slurping and barfing switch to a totally unrelated scheme, by both adding Shift and swapping over to the arrow keys → / ←.

The only obvious similarity of backward editing to forward editing on Linux is the awkardness of using ☚ left for "barf" and ☛ right for "slurp", instead of the more obvious choice of ☚ left for "backward" and ☛ right for "forward". The incongruity is most stark with "barf backward" using → to indicate a backward action. 🤷 This left/right problem also exists even in the not-as-bad defaults for Windows/Mac.

All-in-all there is very little to anchor onto for memorization. And even once memorized, cognitive dissonance persists.

I propose 2 alternatives to drastically improve consistency for these vital editing shortcuts.

---

The first suggestion
--Provides maximum self-consistency within the collection of slurp/barf commands.
--Aligns physical directionality on the keyboard with directionality of the command.
--Uses only Shift to differentiate slurp from barf.
--Consolidates Linux/Windows/Mac all to a single set of hotkeys.

• Slurp forward: CtrlAlt + .

• Slurp backward: CtrlAlt + ,

• Barf forward: CtrlAltShift + .

• Barf backward: CtrlAltShift + ,

---

The second suggestion
--Minimizes alterations from the existing schemes.
--Still incorporates natural directionality.
--Even if not perfect, stil matches more similar commands to more similar keystrokes on Linux.
--Uses only Shift to differentiate slurp from barf on Windows/Mac, but fails to make slurp hotkeys almost-the-same as barf hotkeys on Linux.
--Still requires learning different shortcuts to swap between operating systems.

• Slurp forward:
  on Linux: CtrlAlt + .
  on Windows/Mac: CtrlAlt + →

• Slurp backward:
  on Linux: CtrlAlt + ,
  on Windows/Mac: CtrlAlt + ←

• Barf forward: CtrlAltShift + →

• Slurp backward: CtrlAltShift + ←

[bpringe]

@PEZ Correct me if I'm wrong but isn't the intention of the directions in both the barf a slurp case to be based on the movement of the opening or closing paren? I'm not saying it should or shouldn't be that way, but that at least seems to make sense to me.

If I slurp forward, I move the paren to the right (→) of the next form that I'm bringing into the current form. Then if I barf forward, I move the paren to the left (←) of the last form in the current form.

So to me, it makes sense to stick to basing the direction on the movement of either the form, or the paren (which Calva does).

I don't know what people are used to from other editors, though.

[skylize]

isn't the intention of the directions in both the barf a slurp case to be based on the movement of the opening or closing paren? @bpringe

The command names emphatically imply otherwise:

• Slurp forward ≅ consume expression immediately to the right of current form
• Slurp backward ≅ consume expression immediately to the left of current form
• Barf forward ≅ expel last expression within current form to the right
• Barf backward ≅ expel first expression within current form to the left

The metaphor describes movement of expressions, not movement of parentheses. If we want to impose a mental model of "move parens right/left", we should abandon the the terminology of "slurp" and "barf" altogether and give those commands names that match said model.

[PEZ]

My mental model seems to be the same as @bpringe's:

• slurp forward: consume the sexp forward of the closing paren by pushing the paren forward.
• barf forward: expel the last forward sexp by pulling the closing paren towards me.

ctrl+alt+right/left fits this model for me.

I seldom slurp and barf backward, but my mental model is the same here. I'm pushing or pulling the opening paren in order to slurp and barf things backward from the cursor. ctrl+alt+shift+right/left fits in my mind.

[bpringe]

When I look at how it's done in Emacs, the directions of the shortcuts do correspond to the movement of the expression, and not the bracket.

I don't think I'd be opposed to changing the default shortcuts to that method, but I don't know how challenging that might be with Calva's current default shortcuts (modifying default shortcuts can be a pain). Also, the change could be pretty jarring to some users who are used to the current method.

In the meantime, @skylize, you can change these keybindings yourself, and if you find a good collection of shortcuts that work well with each other and don't get in the way of other Calva shortcuts (or if you have ideas about changing the ones they might get in the way of), it would be great if you shared that info here.

[bpringe]

I do want to point out, though, that at least Calva's documentation for paredit describes each command in relation to the movement of the bracket.

[skylize]

In the meantime, @skylize, you can change these keybindings yourself -@bpringe

Yep. Did just that. But that only helps me. I feel like the current defaults add an unnecessary barrier to entry. It's hard to learn and assimilate contradictions.

A reasonable alternative is changing the command names to something that clearly aligns with intended behavior... at the cost of losing cool-sounding names and a connection to the legacy of lisp writing in Emacs

and if you find a good collection of shortcuts that work well with each other and don't get in the way of other Calva shortcuts

Currently set mine to my first suggestion in the original post. Relieved confusion, and working great. It's all consolidated and internally consistent.

Only a single conflict with existing Calva shortcuts, which only confilicts on Linux. CtrlAlt + , becomes Slurp backward instead of barf forward. No conflict with VS Code, nor with any system-wide defaults that I know of.

Bonus: it frees up prime real estate on the arrow keys for setting up other directional hotkeys.

Shuffling that around a bit gives yet another viable option, by assigning Shift to mean "backward". This is closer to Emacs, and harkens to some very common shortcuts like Alt Shift + Tab to cycle windows in reverse order.

• Slurp forward: CtrlAlt + .
• Slurp backward: CtrlAltShift + .
• Barf forward: CtrlAlt + ,
• Barf backward: CtrlAltShift + ,

The big difference here, compared to current settings, is the removal of arrow keys directly contradicting the command names. This has the added advantage of zero conflict with current options, even on Linux.

[PEZ]

I like the last suggestion a lot, because it is a minimal change compared to the current bindings in terms of keys that change, while removing any contradiction in direction (that I don't feel, but I guess some people do). The current bindings on Mac are a bit problematic because they are often used for Mission Control or by window tiling managers.

A problem with ”shift means backwards” is that in Calva, and in VS Code and most editors, ”shift means expand selection”. We have that situation already, and maybe it isn't such a big conflict since we are talking about editing commands, rather than movement.

Changing keyboard shortcut defaults is a major disruption. We've bitten the bullet before, but it was after serious considerations. If we do this change we'll need to help the users with the transition. Making this quite a lot more work then simply configuring some new defaults. So far, among thousands of users we have had very little indication that people find the current bindings problematic. That doesn't mean they aren't, we just lack a signal strong enough to warrant the disruption and the work. Maybe we can find a way to ask enough Calva users in a good-enough way to get the information we need for making this call?

[bpringe]

Regarding that last suggestion, I think I'd prefer not to have the same directional key be used for both forward and backward for a given action, with another key like alt being used to dictate backward. That seems less intuitive than the current arrangement to me. I'd rather the directional keys match the movement of either the paren or the expression.

I agree, though, that we should get more input on this before making any change to defaults.

[skylize]

I think I'd prefer not to have the same directional key be used for both forward and backward for a given action - @bpringe

I don't think . and , inherently imply directionality. They only seem directional under current settings, because of the close relationship to shortcuts that use arrow keys.

[skylize]

... Unfortunately, as I get deeper into learning the shortcuts, I am finding a common theme that the command names are directly contradicted by the selected shortcuts.

For example, we have CtrlShiftAlt + ↑ for Select Backward Down Sexp. As I watch the animated example in the docs, I can guess at the reasoning behind the choice: "moves the cursor toward the top-left corner of the document". But just like with my original proposal, it does not align with the command name.

With that in mind, my original proposal seems pointless on its own. It is only one step in a piecemeal approach to the problem.

---

So, I have 2 alternative proposals:

1. Rename the editing commands to describe their behavior in relation to implemented shortcuts. Then move the current (inherited from Emacs) command names to parenthesized notes in the docs.

   • E.g. Slurp forward could become Move bracket right with a documentation note of "equivalent to Paredit Slurp forward.

or

2. Work out a new shortcut scheme that fully honors the Emacs command names, while remaining intuitive and mimicking the current scheme as much as is reasonable. Add that scheme as an alternative, which can be enabled by a simple checkbox in the Settings.

   And if proves popular and/or actually helpful to noobs (which is the whole point), then discuss the possibility of swapping which scheme is default for new installs.

[bpringe]

I don't think . and , inherently imply directionality. They only seem directional under current settings, because of the close relationship to shortcuts that use arrow keys.

I think we disagree here, then, unless I misunderstand. Two keys next to each other being used as shortcuts, the left of which corresponds to an action that moves something to the left, and the right of which corresponds to an action that moves something to the right, implies direction, in my mind. Then the fact that (on my keyboard, at least), the left key contain < and the right key contains >, adds more directional meaning.

I'm not opposed to making changes where they seem to benefit many users, but we really haven't seen many (maybe a few, if any) users bring up this same concern. We'd be more inclined to want to make a change like this if more users shared a similar concern. Maybe you can poll other users in the Calva Slack channel and post a link to this issue.

[PEZ]

I think we shouldn't read too much semantics into the shortcuts. Commands like backward up and forward up are conceptually very similar, but one generally moves the cursor backwards and the other forwards. The shortcuts builds on this cursor movement. Same for backward down. and forward down. This works fine in practice,

We're reluctant to cause disruption unless there is a clear signal that users experience problems. The only such signal I have seen is that MacOS often binds shortcuts involving arrow keys, which could be a reason to try avoid those.