Add keyboard shortcuts

[adrianthedev]

I like what Yaro is doing here.

Maybe this is going to be easy to add.

[tumes]

I have a fun idea for this… I’ll try to put together a proof of concept tomorrow (8-12 hours from the time of this posting in terms of my time zone) and pass it along if the idea has legs.

[adrianthedev]

awesome! Let me know if I can help.

[adrianthedev]

... and thank you!

[tumes]

I apologize, it was a very busy day and I had very little time to work on this. The tl;dr is that since the toolbar is fairly loaded (and because, admittedly, I am a vim guy), I had a random itch to make a sort of vim-adjacent text selection and manipulation controller that 1) speeds up text selection and 2) captures most keypresses to open up the field for shortcuts since most keys and combos are pretty well sequestered already.

Technically this is agnostic due in no small part to not having the time to really dig into and understand the marksmith code, and I apologize in advance because I do serious javascript so infrequently that my code on that front is pretty awful. That being said, this may be a terrible approach, but this is my proof of concept with some very barebones basics hooked up:

https://vimish-controller.glitch.me/

Here's my first pass, I have a couple other basics in mind but I didn't want to spend much more time before I thought about whether this was even a good idea. The current features are:

• You enter "selection mode" by pressing ctrl + j while you are the the textarea. This adds a hastily put together border around the textarea to indicate that you are locked into that mode. This could easily by a config item.
• Much like vim, you can just spam esc if you're lost to return to normal mode.
• Left and right arrows expand your selection by one "chunk" (meaning the next outer word character boundary up to the beginning/end of the doc respective to the direction you pressed). I started on up and down arrows as well but I want to think through what makes the most sense for all the weird edge cases that discontinuous movement implies.
• Shift + left arrow and shift + right arrow contract your selection by one chunk from the direction of the key you pressed until you're down to a single word.
• A small selection of keybinds that correspond to items on the marksmith toolbar (b for bold, i for italic, h for header, o for ordered list, u for unordered) just log an acknowledgement that they were hit to the console. If this is worth pursuing, I reckon they could be called via outlets or some other mechanism to knit the functionalities together.
• Ideally I'd pepper in various "vimisms" but the only one in there now is a command to reselect the last selected block if you re-enter selection mode after dropping out. That is mapped to v, though in vim it's gv so suffice to say if I did bake in vimisms I'd want a subset that makes sense in the context of this use case while also leaving the letters that map to main toolbar functions open since I figure that using the first letter in the tool name is the only way to plausibly make it palatable for an average user.

Anyway if nothing else it was a fun experiment, though I do genuinely think that plain keybinds might get lost in the shuffle, that isolating keypresses into a mode is at least a way to have any assurance that there would be enough free to keep it robust, and that quick text selection enables enough of a power user experience that you could get away with never taking your hands off the keyboard for long stretches.

[tumes]

I should also add that I’ll probably tinker with this regardless, so no problem if it doesn’t seem like a good fit, my general idea is that it’d be agnostic enough to be usable down the line if it’s of interest and more fleshed out.

And the vim-like stuff I figure would be must haves would be vertical selection, and more specifically a line select mode for lists. Almost anything else would be power user nice to haves, like up and down casing, maybe some bastardizations of common vim things (add from start/end of line, delete selection, maybe a search function). I mean many OSes can do that natively but I always struggle to recall and context switch the varying implementations. There’s so much scope to creep but I think centering things around a subset of visual mode-like controls and consequently operations on blocks of text are where any real usefulness lies.

[adrianthedev]

Oh man. That's a lot.
I'm away with the family right now, and I'll have a look next week.

I think the initial iteration should definitely have the "regular" shortcuts for text styles.

Well figure out a way🙌

[tumes]

For sure! I don’t disagree, this was as much a fun exercise as an attempt to strictly meet the intent of the issue. I’ll take a quick swing at a pared down version that captures just the main style modifiers… I’d still argue some amount of modal editing makes sense, eg if there is an active selection within the text it can be a little more aggressive about capturing key combos that might otherwise be sequestered by the browser or OS if there is a collision with the most obvious character or combo. Though just having a shortcut to trigger “**” so you can drop it wherever then navigate to drop the closing half somewhere else could also make sense.

[adrianthedev]

Yeah... I think it's a bit outside the scope of this issue :P
With this issue I'd like to add the basic keyboard shortcuts...

I'll tell you what. We'll take a PR that adds StimulusJS controllers to the editor and this kind of behavior can be added.