Allow paredit commands to accept args - and use them for multicursor & copying when killing

[riotrah]

What has changed?

The philosophy behind this was already described in the private calva team chat, but I can repost here if desired.

• Makes /src/paredit/extension.ts multicursor and kill cmds accept an arg, for now a map with a single key for each respective type of command.
• The multicursor paredit commands' args looks like {multicursor: boolean}
  • When this args map and entry are non-nil, override the workspace or user config for calva.paredit.multicursor for that particular keybinding.
• The kill commands' args looks like {copy: boolean}
  • When this args map and entry are non-nil, override the workspace or user config for calva.paredit.killAlsoCutsToClipboard for that particular keybinding.

This will only affect users that utilize these args. There have been no documentation additions so if merged as-is there should be no changes for anyone, but if we like this idea, we'll want to probably mention this somewhere.

I will do some more changes here, like fortifying the static typing and CHANGELOG entry, and aforementioned documentation, and perhaps some basic tests, if we like this idea overall.

I'll create an issue if we like this idea.

Fixes #

My Calva PR Checklist

I have:

• Read How to Contribute.
• Directed this pull request at the dev branch. (Or have specific reasons to target some other branch.)
• Made sure I have changed the PR base branch, so that it is not published. (Sorry for the nagging.)
• Made sure there is an issue registered with a clear problem statement that this PR addresses, (created the issue if it was not present).
  • [] Updated the [Unreleased] entry in CHANGELOG.md, linking the issue(s) that the PR is addressing.
• Figured if anything about the fix warrants tests on Mac/Linux/Windows/Remote/Whatever, and either tested it there if so, or mentioned it in the PR.
• Added to or updated docs in this branch, if appropriate
• Tests
  • Tested the particular change
  • Figured if the change might have some side effects and tested those as well.
• Formatted all JavaScript and TypeScript code that was changed. (use the prettier extension or run npm run prettier-format)
• Confirmed that there are no linter warnings or errors (use the eslint extension, run npm run eslint before creating your PR, or run npm run eslint-watch to eslint as you go).

Ping @PEZ, @bpringe, @corasaurus-hex, @Cyrik

[netlify]

✅ Deploy Preview for calva-docs ready!

Name	Link
🔨 Latest commit	e9e8e89
🔍 Latest deploy log	https://app.netlify.com/sites/calva-docs/deploys/6618ae36545eed00081dbb3a
😎 Deploy Preview	https://deploy-preview-2482--calva-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[PEZ]

This is so awesome. The exact right way to go with this.

[PEZ]

I like this idea. Please go ahead with issue and documentation. I think a mention about the arguments could be added as a sub-header just before we mention that strings are treated as lists: https://calva.io/paredit/#strings-are-not-lists-but-anyway

Question. The kill commands support two options in their argument (multi-cursor, copy) right?

[riotrah]

@PEZ

1. I'm working on some documentation, will push, lmk what you think! I'll push in separate commits with the necessary changes for this PR first, then some edits of the rest of the About Keyboard Shortcuts section in src/docs/paredit.md.
2. Nope, the kill* commmands support multicursor behavior nor arg, but when I get to them, their arg will still be a map, but with both keys copy & multicursor.

[riotrah]

My thought was to place them in a sub section underneath About Keyboard Shortcuts, since these command args are only applicable for shortcuts, not any other form of invocation (eg cmd palette, menus, etc).

But if you'd like to surface them higher, I think that could make sense - I'm not particularly partial to either.

[PEZ]

My thought was to place them in a sub section underneath About Keyboard Shortcuts, since these command args are only applicable for shortcuts, not any other form of invocation (eg cmd palette, menus, etc).

A thing with commands is that they are API. Even if keyboard shortcuts are an obvious place where this API surfaces it doesn't stop there. They may be used Joyride scripts, or from some other extension. That said, I'm totally fine with this going to the Keyboard Shortcuts section.

That commands are API also means that we need to be careful around them. Whatever we add we may need to support forever. Dunno what this says about the multicursor option, come to think of it. But if you flag that in the documentation as potentially temporary, we should be fine.

[riotrah]

Ah yes, good point

[riotrah]

Might be worth introducing the concept with kill+copy in the section you'd suggested, and allude to that in the experimental multicursor section at the bottom. Maybe we rename to experimentalMulticursor?

I mean, technically, if we kept multicursor as-is forever, we would "just" disable multicursor for a given cmd invocation

[riotrah]

@PEZ I've pushed a couple commits, feel free to review by commit. Namely, the last two:

• last: an unrelated edit of the About Keyboard Shortcuts section
• 2nd last: the relevant command args additions

[PEZ]

Sorry for the delay. LGTM!

[PEZ]

Regarding the note about fallback for grow/shrink selection. It reminds me that I haven't checked if the multi-cursor selection commands participate in the grow/shrink. I now checked, and they don't. Anyway, could be good to look at this, as it may be important for the general architecture of the multi-cursor editing.