@UKFSJSM38 I created a stand alone json file that contains all of the lsp commands, along with the shortcuts and improved docs. Would this be helpful to upstream? (I also noticed that demote-fn has the same shortcut as drag-forward, so I changed it to dm for coc-clojure)

c/c @U07M2C8TT is that shortcut conflict expected?

I think I noticed the conflict a long time ago, but then forgot about it. Personally, I used Cmd-DownArrow for drag forward, so df works for me as a shortcut for demote-fn. I could adjust to dm if that becomes the standard, although it loses symmetry with pf for promote-fn. In general I don't have strong opinions about the shortcut recommendations, except that I think it's nice if they agree with the old clj-refactor shortcuts. But since clj-refactor didn't have either of these commands (though it did have promote-fn) that consideration doesn't matter as much.

Err, rather, I use Ctrl-DownArrow. I think I got that from TextMate, although I think it's the default for lots of other text editors too. Maybe different on Windows

I use Ctrl-Alt-up/down for the drags, but I totally agree with @U07M2C8TT

@UEENNMX0T we already have a table with details about the commands + gifs, if you think there is something there to be improved, feel free to raise a PR

I don’t have any opinions on what the shortcuts of either set should be, they just have to be distinct for me to implement them in my extension as the extension doesn't and can't know the context of the call to decide which to execute.

Next time I'm on my computer, I’ll open a PR with my doc changes. Hopefully they'll be helpful

Maybe @U0BUV7XSA could help with suggestions for the shortcuts?

Thank you @UEENNMX0T for pointing that out. @UKFSJSM38 The key is we cant have conflicts, so that clients can promote the same shortcuts. I don't know the timeline between the drag rename and demote being introduced. I know we talked about drag naming and promote-fn but i dont recall a discussion about demote. I think conflicts are generally an analysis of: 1. what's already defined in the project. 2. what's already named elsewhere. 3. symmetry with reverse or similar ops 4. semantics of the full name 5. ease of shortcut mnemonic I think dm is not great (I would probably train myself to think "DEE mote"). Renaming demote-fn is perhaps the thing to do. Does cursive have a similar refactor? I feel clj-refactor called similar things inline as it's removing the name.

Any reason we shouldn't suggest the arrow keys for dragging, since that seems to be common usage? That leaves df for demote-fn, emphasizing symmetry with the more established pf for promote-fn. It would vary from the existing mnemonics in that it would use symbols not letters, but sticking to letters is a vim-centric norm

Hrm i think they are different than keyboard shortcuts. You also have helm(?) style menus, spacemacs chords, and menu navigation like alt-f-s for file-save etc in most OSes.

I dont they would be happy with arrow keys

I'm not sure whether you're disagreeing or agreeing @U0BUV7XSA Are you saying dragging is more like an OS level thing, and therefore arrow keys make sense? Who is “they” in your second reply, or is that a typo? To me, inline doesn't have the right semantics for what demote-fn does. It changes an fn to an #() while leaving it in the same spot. In my mind that's very different from inlining which involves removing a name and moving a block of code.

Disagreeing. The idea of sequence of letters pointing at a function is not vim centric. The examples I cited are "they" (except spacemacs chords). Arrows are highjacked for navigating the menus linearly while shortcuts navigate through submenus directly. Good point about inline.

Yeah, unfortunately having letters as suggested keybindings will always be what works best for most clients, a specific client can always change that to other keybinding too. How bad is consider suggesting a keybinding with mor than 2 letters? Although changing the word demote/promote to something clearer/different sounds better indeed

I’m still not completely following. I think you’re saying that if you bind drag to arrow keys, you have to be cognizant of what you might be overriding. There are other features of your editor and of the OS that might be using arrow keys. That’s true. @UKFSJSM38 and I have found ways to use the arrow keys, and I think other people have too, but that doesn’t necessarily mean it’s a good suggestion for us to make. Something to keep in mind with drag is that though it might be possible to assign a two-letter keybinding to it, that’ll be terribly unergonomic. Dragging needs to be easily repeatable, preferably with a single key, so you can drag several positions at once. It’s really uncomfortable to use a two-letter keybinding for that (especially when you add keys to open the command palette). So in practice it’s unlikely anybody will ever use a two-letter keybinding. Because of that, the best option, IMO, might be to omit a two-letter suggestion for drag. Client implementors will have to make their own decision about how to invoke drag, but if they want to give their users something ergonomic they’re going to have to do that anyway

keyboard bindings and the two letter mnemonics are just different things that usually but not always overlap. mnemonics really follow what i first saw spelled out in spacemacs. but you could argue that os menu systems "File/ Edit/ Help" did this first. hydra (not helm, sorry) is another example. the idea is to put common functions in one place with unique bindings. If you have the prefix, i use cr, then all the functions are discoverable and you start building muscle memory to do the various functions cram , crpf etc... Now those functions might have more convenient keyboard shortcuts as well but being able to hold everything in one place has proven useful. In windows you can hit alt-e-s to open the menu with a list of structural edits in cursive and you can hit the follow up keys to execute or see more convenient keyboard shortcuts.

@UKFSJSM38 more than two could work but you wouldnt want conflict in the prefix like df and dff