Keyboard commands constraints about roam-toolkit

[Stvad]

we can do ctr-a/x to map on vim behavior (https://vim.fandom.com/wiki/Increasing_or_decreasing_numbers) as an option

[PiotrSss]

up/down is more obvious and easier to use, imo, as a default, and users would be able to change that later anyway. Or have it blank by default and require to specify shortcut when feature is turned on first time

From what I understand ctrl+up/down will interfere with expand/collapse on Windows? It's fine on Mac, we have cmd+up/down to exp/collapse, so we can use something like:

"default": "Ctrl+Shift+Up",
"mac": "MacCtrl+Up"

if Ctrl+Shift+Up/Down is free to use on Win?

[PiotrSss]

Also it seems we can't use shortcuts that are already used by browsers. I wanted to implement item/selection duplication - code works, but the best possible shortcuts are not available, "Shift+Ctrl+D" works in Chrome, but for some reason not in Firefox. "Alt+D" generates letter, "Ctrl+D" removes one character. Can we somehow prevent default behavior?

[dalmo3]

up/down is more obvious and easier to use, imo, as a default, and users would be able to change that later anyway. Or have it blank by default and require to specify shortcut when feature is turned on first time

If with time we're having tons of shortcuts, better define default ones that work out of the box.

From what I understand ctrl+up/down will interfere with expand/collapse on Windows?

Yeah you lose ability to exp/collapse with those keys, but Ctrl+Space does that as well, which I personally prefer.

if Ctrl+Shift+Up/Down is free to use on Win?

It's free as in - not a browser shortcut, but it's used for text selection so I wouldn't touch it.

[Stvad]

I believe that overriding default shortcuts is a pretty bad idea. So even if we could do it - we shouldn't.
Ctrl-up/down are default in mac for expose/desktop manipulation stuff.

maybe alt +/alt-?

[PiotrSss]

Hmm, ctrl+up/down does nothing for me wherever I try that.
alt +/alt- creates – and ≠, same story as with my alt+d=∂... I have nothing against, but we need to override that default behaviour, because right now code in browser.runtime.onMessage.addListener((command) => { is not running in such conflict scenarios.

[dalmo3]

Just ran into this message
Too many shortcuts specified for 'commands': The maximum is 4.

So apparently we can only add 4 default shortcuts. It's possible to define more commands in the manifest but user needs to define their own shortcuts.

There's suggestion to use a single shortcut to open the extension and then capture the commands from inside the extension, possibly making it emacs-like. I can see that working well with ingestion and other stuff that rely on external services, but it's too much friction for simple stuff like inc-dec ...

Maybe for block manipulation shortcuts we can add the event listeners into the document itself?

[Stvad]

It's possible to define more commands in the manifest but user needs to define their own shortcuts.

that's dumb.

Maybe for block manipulation shortcuts we can add the event listeners into the document itself?

yeah, we can do that, but then we'd need to have a custom way to configure this =\

[dalmo3]

I suppose now with the dispatcher we'll move most/all of the in-roam shortcuts into it and leave the manifest only for those shortcuts that need browser/global activation?

[Stvad]

um, yes if you refer to things in #16, dispatcher refers to something a bit different in my mind (that is supplanted by #16)