Moving a block up/down only works in edit mode and not in navigation mode

[ChrisVn]

I am reporting this unexpected behaviour as a bug, as it goes against what is probably intended.

Moving a block up/down only works only in edit mode and not in navigation mode.

This is contrary to the usual behaviour that actions are available in both modes, such as folding/unfolding blocks, which also works in both modes.

[sabre23t]

I added a vote to your request.

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.

[ChrisVn]

Thank you for your vote and for your thoughts.

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 …

Clear distinction between editing mode and navigating mode for shortcuts

Similar to VIM or Checkvist (an online outliner), I would like Logseq to make a clear distinction between editing mode and navigation mode. This would be important so that keyboard shortcuts for editing text do not get in the way of navigation shortcuts. For example, moving and collapsing blocks should NOT be possible while writing blocks, but only outside of editing mode. So when writing text (editing mode) SHIFT+left/right/up/down or also CTRL+SHIFT+left/right etc should be available to sel…

… 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.

[tienson]

Just adding some related information, there’s a PR on GitHub for moving selected block(s) and move them up/down, [WIP] feat: Move selected blocks up and down by nickdex · Pull Request #2235 · logseq/logseq · GitHub

[ChrisVn]

@tienson Thanks for adding this related information. It gives us another reason why moving in navigation mode should be possible.

Only in navigation mode you can select multiple blocks. And so, only in navigation mode there would be a possibility to move multiple blocks at once. And that’s something really useful.