My POV on Shortcuts

Hello! Apologies for the ambiguity in the title, but I think it fits best considering that the points that made below are my takes on Anytype’s shortcuts.

I want to bring up some points regarding shortcuts in Anytype; for readability, I’ll help to section off each idea into different headings. As much as possible, I’ll include screen captures to help you understand my point of view better.

General text selection

I find that it could get incredibly frustrating when trying to select multiple lines. I understand, though, that this may be due to the way Anytype was designed. Having a block-like system restricts how text can easily be selected if cordoned off in different blocks. I can’t include a screen recording here to explain, but I’ll give a scenario for you to envision.

These three lines are separated into three separate blocks; this behaviour is expected in Anytype, of course. Usually, in a simple text app (e.g., Word, TextEdit, Notepad), command/control-shift-up would select the line above. Instead, Anytype behaves differently (the way I can describe it is similar to JetBrains IDEs) — Anytype shifts the entire block above.

This issue is also prevalent when trying to click-and-drag the cursor to select multiple lines of text. Instead of the selection stopping at the cursor, Anytype selects the entire block instead.


I think these two behaviours may be a problem for those unfamiliar with them; we can probably expect most of a standard user’s experience in Anytype to be dealing with text. Considering that the standard that many, many apps have right now would be to instead select the text from the line above, I think that there may be a need to introduce this ability! I particularly like [@Oshyan’s idea of having multiple modes](Proposal: block edit vs. text edit "mode" with hotkey or modifier) — a text, hybrid, and block mode. This way, we’ll be able to cater to two worlds — the text-only world (where it may be more appropriate to have command/control-shift-up and -down select the text in the line above/below respectively) and the block world (where it may be more appropriate to leave things as it is).


Toggles are a pretty neat feature, to begin with (I just found about them today by accident by typing >, and I can’t stop using them!). Nevertheless, I think that it may still be a little clunky. One distinct odd behaviour is captured in this video.


This involves using the command/control-shift-up or -down shortcut. When a sub-object the first or last item in a toggle, and -up or -down is pressed (respectively, of course), the object moves out of the toggle. That makes sense to me.

To move an object into a toggle, though, is where I find a little peculiar. Moving an object into a toggle only works if:

  • the object is below the toggle (and therefore only command/control-shift-up works)

  • the toggle is not empty

I think it’ll be better to improve this a little bit, such that command/control-shift-up or -down would move the object into a toggle if it is below or above one respectively. If the user would want it to stand on its own, the user will have to use the command again until it moves out of the toggle.

I think that it’s also slightly weird to have the object inserted as the first object in a toggle every time (see how Subtoggle 1.2 is placed at the top inside Toggle 2). Perhaps it’ll be better to insert the object at the end of the toggle instead?

Also, notice how the object becomes unselected after it has been moved into a toggle. I think it’ll be neat to have the object still selected even after being moved inside a toggle (Subtoggle 1.2 lost focus after being moved into the toggle).


That’s all that I have to say now. Of course, this is all my opinion; I won’t know if any of you agree with some of the points I’ve made. If you do, please let us know here! It’ll be a great point of discussion for general shortcut behaviour here, too.

Thanks for reading it this far (or perhaps you’ve skimmed through it? That’s fine, too).