However, looking at Logseq v0.2.5 “Customize Keyboard Shortcuts” and specifically its “Navigation” section I see …
(1) Some commands that works differently in edit or non-edit mode: up, down, left, right, alt-right, alt-left
(2) Some commands that works the same in edit or non-edit mode: ctrl-up, ctrl-down
(3) Some commands that only works in non-edit mode: t o
It is possible the “navigation in non-edit mode” is intended for just that limited navigation (non-edit) purposes, rather than a generalized special mode on its own.
Also, not enabling moving blocks (an editing function) in a “navigation (non-edit mode)” context, may be a good rationale by itself.
I think your points reflect the problem I’m still having when trying to understand LOGseq.
(The problem here is that I can only speculate what picture the developers themselves have of this. In the worst case they don’t have a clear picture themselves )
As discussed here …
… there seem to be some (few) reasons why we need 2 modes at all. But basically LOGseq seems to rather go the way of not wanting to discourage users by too strict separation between modes.
This bug report was also written under this assumption. Previously, I actually thought the separation into the two modes was not clean and the boundaries should be clearer - but I can understand the argument that not everyone would get along with a clear but strict separation like in VIM - that could scare off many users (because this concept is not the dominant one) .
Then there is also the question of what is actually meant by “editing” in edit mode. Just writing text or more? Also the deletion of blocks? Because the argument: “moving a block is also a kind of editing” would apply just as well to “deleting blocks” or “intending” blocks (which is already possible in navigation mode).
I would like to be able to do all those “restructuring actions” in navigation mode.
For me navigation mode means working with whole blocks. So I can navigate and select one or multiple blocks and restructure the outline (or delete some blocks) and so on. This at least feels natural to me.
Either we try to separate the modes clearly or we try to make the boundaries disappear as much as possible. It’s a conceptual decision. If we try the latter, moving blocks is clearly missing from the navigation mode.