Paredit: support "raise" and "splice"

[pesterhazy]

Fantastic to see expand-region (Cmd-[ and Cmd-]) in maria - it's one of the most intuitive selection primitives.

It would be great to have also paredit shortcuts that allow you to splice a form into its parent.

Paredit usually supports three variants:

• paredit-splice-sexp-killing-forward
• paredit-splice-sexp-killing-backward
• paredit-raise-sexp

Raise is the most useful variant IMO, but paredit-splice-sexp-killing-forward can help as well, e.g. when removing a let.

[mhuebert]

Tracking these now in #50

[mhuebert]

@pesterhazy in the dev channel, some new paren-related behaviour has been introduced:

1. splice via Option/Alt-S or by pressing backspace in front of an opening paren. (eg. (|a) + backspace = |a - took some inspiration from parinfer here)
2. Hold Command/Control and use the arrow keys to expand the selection left/right/up; the down arrow returns the selection step-by-step to the starting point. Add the shift key to select the top level form.

Example doc: https://dev.maria.cloud/gist/7b46a1be3c6e2c25766148e255719220

Feedback welcome!

[pesterhazy]

Nice! Some feedback:

• expand-region is intuitive and command+arrow keys are great keybindings for it. However, Mac users may be used to seeing Cmd+left and Cmd+right to for HOME/END (although ^A/^E still works). But I have to say your version is even better than expand-region, because it allows you to expand both ways!
• not sure about splice. I know this under the name unwrap. I tend to use raise more often than unwrapping.
• really like backspace to unwrap
• in the example :b doesn't seem to be recognized as a symbol when using Cmd-left and right

[mhuebert]

Thanks for the feedback! Good call re: splice vs unwrap. Didn't realize splice was something else. I found the M1-arrows took a small amount of getting used to (esp. left and right), but seem worth it for the ease of explanation and remembering overall. Also, because of how shift expands an M1 selection to the top-level form, M1-Shift-Left/Right has the effect of moving the cursor to the left or right of the top-level form. I am not sure exactly if this is what you were referring to about :b, but currently expand-selection-left/right starts from the cursor and doesn't expand 'up' to cover the whole token before moving to the next form. This was intended but am not sure it is the right thing to do. Maybe it's more likely that you would want to select the whole form - and it would be simple to delete just the right/left segment of a token first as a separate step. I'll look at raise.. Maybe by adding shift to the unwrap command. So if I understand correctly, 'raise' replaces the parent sexp with the thing selected.

On Fri, Sep 1, 2017 at 02:51 Paulus Esterhazy ***@***.***> wrote: Nice! Some feedback: - expand-region is intuitive and command+arrow keys are great keybindings for it. However, Mac users may be used to seeing Cmd+left and Cmd+right to for HOME/END (although ^A/^E still works). But I have to say your version is even better than expand-region, because it allows you to expand both ways! - not sure about splice. I know this under the name unwrap. I tend to use raise more often than unwrapping. - really like backspace to unwrap - in the example :b doesn't seem to be recognized as a symbol when using Cmd-left and right — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKFZ16-AQAxVAaS5tbN3_4eZr06zmWKks5sd1T-gaJpZM4OgbZ9> .

-- http://matt.is — Berlin, Germany --

[pesterhazy]

Right, my point was that it would be great if :keyword was always treated as an atomic token, rather than composed of : and foo - it felt as if they were separated when I was experimenting.

FWIW I did a presentation about structural editing earlier this year: https://youtu.be/ubcERtDyLDw?t=10m52s with my attempt at explaining splicing/raising after the 18m mark.

[mhuebert]

Ah, I can see how it would feel that way, depending on where the cursor starts:

but again, I'm not sure this is ideal. maybe it makes sense to grow the selection to the whole token before expanding out to the right.

Thanks for the link to the presentation. I'd like to think about which commands would most need their own shortcut, vs. being easy/fast to achieve using selections with copy/paste. Since M1 (command/control) both selects the form & is also combined with C and V for copy/paste, one can do a lot of manipulation with very few keys to memorize -- eg. Raise:

While holding Command/Ctrl...
     - C (copies form)
     - Up x2 (selects outer bounds of parent form)
     - V (pastes form)

Not quite as fast as a dedicated command, but after learning Command + arrow keys, one could discover manipulations like this intuitively without ever needing to know the special names or bindings.

[pesterhazy]

All good points. One last point in favor of raise is that it neatly corresponds to a logical operation, for a lack of a better word. For example

(if condition? (foo) (bar))

If you realize that condition? is always true, you can just raise (foo), eliminating the conditional in a single operation.

[jackrusher]

One way to think of the difference between paredit, which has many special commands for different actions, and this selection-based approach is like the difference between an object with many special purpose methods and a data structure with a small number of composable functions. If we can discover a good set of interaction primitives here, there's simply much less to learn/memorize/practice to reach a high level of ability in structural editing.

Also, once we have this basic set of orthogonal actions, it should be trivial to support an extension mechanism that allows on to combine them into single commands that can be bound to keys by those who want them. (For example, a raise function could be added as a user defined function that calls select current form, select-up, select-up, paste-replace).

[mhuebert]

I like this idea of giving nice names to these primitives & making it a simple matter to combine them into bind-able commands.