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 select text.
Outside of editing mode, however, there is little to be said against not being able to use these shortcuts, e.g. to move blocks etc.
While writing text in Logseq, only the usual shortcuts of a text editor should be used. Outside of the editing mode, shortcuts should be available for moving, expanding/collapsing, etc.
In the end, this feature request actually means that shortcuts such as collapsing/expanding or moving blocks should not be assigned to the editing mode, but to the navigation mode.
There are 100% modal editors (VIM) and there are 100% modeless editors (Notepad).
It appears to me, Logseq outline editor is mostly modeless as default interface shown to users (with a few non-edit mode commands). However, logseq internally are 100% modal, some of the modes I noticed are:
1/ Block edit mode (the most common mode), where there is a blinking vertical cursor in the block being edited.
2/ Block non-edit mode (press esc key from block edit mode), where the block is highlighted in grey background.
3/ Non edit mode (press esc key again from block non-edit mode), no vertical cursor, no block background highlighted.
In last few Logseq releases (current 0.2.5) the Help/? button will show you Keyboard Shortcuts next to Customize button that will show you all shortcuts and ability to customize all of those keyboard shortcuts.
I believe what you wanted above can be done with such customizing Logseq keyboard shortcuts.
If Logseq wants to go full modal, I strongly recommend making it optional. People who use modal editors don’t realize how confusing it is for the average user, and Logseq should not create an obstacle for the 90% of users who don’t want to climb the modal learning curve.
After reading it, I am not sure if Logseq is now modal or what would be the difference being 100% modal.
There are already these two different modes and different actions are possible in each mode. I can’t write text in navigation mode and vice versa some actions are not possible in edit mode.
What Logseq does differently (than e.g. VIM) is that there are quite a few ways to switch to edit mode (e.g. a simple click in the block is enough). So it feels more like an editor and you have to change to navigation mode intentionally - not the other way round.
Nevertheless, there are those 2 different modes and I would like to suggest to distinguish these modes more clearly in order not to block the usual shortcuts when writing text. I don’t want to make it more difficult for the average user - I want to make it clearer.
More about this in my reply to sabre23t, which I will write in a moment I will try to show what I mean in regards to folding a block.
First I thought this is not true and part of the problem. Than I did some more experiments and found that I was partly wrong. Many commands (most of the commands?) can be initiated in both modes.
E.g. I can fold/unfold in edit and navigation mode.
BUT that is not true for all commands and maybe I should change my mind here. @Cobblepot maybe what confused me was not an unclear distinction between those two modes but more like a bug regarding the command to “move blocks up and down”.
Because to “move blocks up and down” is something that is NOT working in navigation mode and I don’t see a reason for that.
So we have two choices here and as Cobblepot stated I think the more user friendly one would be: “to allow all the commands in all modes” (at least where they make sense).
(That raises the question for me why we need 2 modes at all. I have to think about that now.)
This was an interesting conversation so far. Thanks - now I understand even better how Logseq works.
I believe the main reason Logseq needs two modes is because Logseq doesn’t have a global file/page edit mode. It only has a block edit mode and global non-edit mode. While editing a page you are continuously changing mode from edit to non-edit to edit when you move between blocks. This “block edit” mode changes would appear more obvious if you have the following CSS code in custom.css. It’ll put a box around the current block being edited …
Thanks - yes this seems like one of the reasons.
Another reason is probably how Logseq treats/renders Markdown.
The Markdown code is only displayed in edit mode. In navigation mode, instead of **bold** you just see bold.
The behaviour is different from “Zettlr”, for example, where markdown AND their renderings are displayed at the same time. (see screenshot below)
The question is, if we want to make it as easy as possible for the users, can’t we do without the distinction between the two modes, at least externally (user interface)?
As I have already written in the screenshot - I myself am undecided what I would find better. Both approaches have their advantages.
Zettlr is a strange mix. It shows Markdown and renderings for style tags, but not for links, where it shows the rendered display text but only shows the Markdown if you click in the link. Since it doesn’t automatically show the full plain-text markdown on the link you are editing, it reflects some personal decisions by the developer on what should be rendered and how (not that that’s a bad thing).
Oh, another reason for non-edit mode is Logseq make use of those two letters commands that only works in non-edit mode: t o, t w, t d, t t, t r, t s, t c.
You can’t click a TODO and so on [while in editing mode]
My personal dislike for this Logseq quirk reduced when I learnt about esc key to quickly escape from edit mode. Before that I thought the only way out of edit mode is to click outside of any/all blocks (and I don’t like moving my hands away from my keyboard to the mouse).
This is an interesting discussion. Personally I think a more defined modal editing could be beneficial for everyone.
Allows a richer customization of behavior for shorcuts an other actions. The most direct example is those t o, t w, t d, t t, t r, t s, t c you mentioned @sabre23t
Richer customization allows a configuration that improves navigation. E.g. moving through blocks, going to the first/last block in the page, moving focus to the sidebar or t the main panel… without leaving the keyboard when not necessary.
It won’t disturb users that are comfortable already with the current state of editing. We could have a toggle that for example makes (oversimplifying) navigation keys = Edit keys and now modal editing is gone.
I think logseq’s design is keyboard centric from the beginning, but it has not reached the full functionality yet.
I have made myself at least one feature request (Make Context-Aware Tab (indent) and Shift-Tab (out-dent) for "in-block" editing (of lists)) that is about having a DWIM (Do What I Mean) approach to editing versus navigating so that a “Tab” while editing would actually print a Tab Character (4 spaces) and not Indent the Block, which gets very messy if done by accident and you now have unintended blocks inside previous blocks.
+1 for Context-Aware Editing / Navigating in the DWIM style.
I will try to show what I mean in regards to folding a block.
