Using TAB for Auto-Completion (Cycling) for "<" -Custom Commands- FAILS

Questions & Help
1

I wanted to make sure that this isn’t something specific to my environment before filling a bug report on github.

I have the following situation: I have TAB and Shift+TAB as shortcut keys assigned in Seetings>Keymao for “Auto-complete: Select next item” and “Auto-complete: Select previous item”. I want to input some custom command in any block and I type “<” then I want to go through the possible options shown in the popup list. The moment I press TAB, the active element in the popup list becomes the next one, as expected, but it is also selected (as if I also pressed Enter), which doesn’t happen in the Main Content Pane and it doesn’t happen if the keys for cycling through the popup window elements are the usual Arrows or Ctrl +N/Ctrl+P.

There is also another quirky thing going on in the Right Sidebar - which I’m actually ok with- is that Macros execute immediately after writing them, sometimes it doesn’t even wait that long and don’t execute after going out of Edit Mode like normal.

PS: this doesn’t happen for “/” Commands, only for “<” Custom Commands … it’s kind of a mess if you ask me.

Edit: ok, I tested with an empty Graph and I get the same behavior. Is this something that has any workaround? Or falling back to defaults (arrows and Ctrl+n/Ctrl+p) is the best option?

2
  • Wherever direction is involved, arrows are always the best option.
    • Combined with modifier keys (Ctrl etc.), they are superior even to Page up/down, Mouse wheel etc.
      • If they are assigned of course.
  • Going up and down a list of next/previous items clearly involves direction.
  • Therefore, going up and down a list is best done with arrows.
3

This is debatable. Reaching for Tab / Shift+Tab is way easier when both hands type at the keyboard. Reaching arrows is not optimal from an ergonomic pov.

But, as long as Logseq lets you re-map the defaults with custom shortcuts, it is strange that the behavior would change for TAB, is has to be a bug…

4

I gave it some more thought and I actually agree with the way Tab works with modal lists. It acts like a Tab-Completion key similar to how CLIs use the double tab to end the auto-completion. It’s just weird that it lets you set tab as a shortcut for :auto-complete/next…