Keyboard navigations shortcuts

Since tienson has made custom keyboard shortcuts possible (yay!), the question now is less about which key-bindings to use, and more about which features can be accessed with key bindings. I’m going to try to keep this post limited to navigating when not in editing mode. (i.e. vim normal mode).

j - Select block below current
k - Select block above current
a - Enter edit mode with cursor at end of block (already exists)
i - Enter edit mode with cursor at beginning of block
o - Create new block below current and enter edit mode
O - Create new block above current and enter edit mode

g g - Go to top block
G - Go to bottom block

Not strictly vim-inspired, but could be helpful in quickly navigating the outline tree:

{ - Select previous sibling block (or parent if it doesn’t exist)
} - Select next sibling block (or next block if it doesn’t exist)
h - Select parent block

Also, it would be nice to be able to move-block-up/down and collapse/expand from non-edit mode. I’ve taken a look at some of the keyboard code and see that edit and non-edit mode shortcuts are handled differently, so this is probably not as easy as it might seem.

Awesome I like this a lot, I wrote the feature request on vim

Vim-mode Powerful Shortcuts

I really hope one day we can have as much as possible of vim in Logseq, but I like how your request @IcedAndCorrected is a great start.

Perhaps I’m not too clear on what’s the best way to start customizing shortcuts in logseq.
To be clear is any of what you are suggesting currently possible? or is everything you mentioned a request for more functionality with shorcuts?


1 Like

I’ve made another post about how to customize shortcuts, which shows all the functions you can currently bind keyboard shortcuts to. My request here is about adding more possible functions we can call using shortcuts, such as select-next-block, which I would map to j. That isn’t currently possible.

And I totally agree about having as much of vim as possible. I just though of another vim feature that’d be great, marks:

m + lowercase letter: set local mark on currently selected block (works within a single page)
m + uppercase letter: set global mark on currently selected block (works within entire repo)
' + letter: go to marked block
‘"’ + letter: open marked block in sidebar

I suspect that would be a long way off, but it would really speed up workflows where you’re reading/editing from multiple pages or blocks.


I completly agree with what you said, and yeahmarks would be a mind blowing feature!!!
Thanks for the resource to your other post on customizing shortcuts I’ll check it out!

Hey @IcedAndCorrected I’ve been playing with this a lot and it’s super helpful. @tienson just created a newa category in the forum called “Look what I built” if you want categorize your posts there that’d be awesome for more people to see it!

It’s moved to the “Look what I built” category.

1 Like

ups I commented this in the wrong one. I meant to say that for @IcedAndCorrected 's other post this one:

Keyboard shortcut customization guide

1 Like

Got it, my bad, I’ll change it back and move that one to the new category :grinning_face_with_smiling_eyes:


thanks! yeah I confused the posts


I would like to see native Logseq support for the Vim commands to move the cursor to a specific character (forward or backward), to the end or beginning of the sentence (≠ line), and so on. These would make Logseq more suitable for longform writing.

1 Like

The problem with this request is that LOGseq does not have such a strict distinction between navigation mode and editing mode as VIM.

We have also discussed this here:

LOGseq is currently following the path of making it easy for the user to write text and, as far as possible, providing the behaviour of a “normal” editor. This means that keyboard shortcuts with individual letters are not available for navigation between words (in navigation mode you are navigating in block units not characters or words).

This is a fundamental decision of the developers which concept LOGseq follows.

The original requirements of @IcedAndCorrected are possible because the shortcuts only refer to the navigation mode and function at block level.