Unable to select multiple lines

[Felix Häusler]

It's not possible to select more than one editor block (e.g. paragraph).

Further issues:

• Ctrl+A select just one block
• Unable to select soft-lines with Shift and arrow keys

Block backport of marktext/marktext#2835 and marktext/marktext#2853, if needed.

[Ran Luo]

Ctrl+A select just one bloc

This function has not yet been developed. There is a difference between the refactored muya and marktext. The entire editor is no longer a contenteditable div. The content block is an editing area, which is a contenteditable element, so now Ctrl + A cannot selecte all editing areas, this requires us to develop separately to handle selecting all.

Unable to select soft-lines with Shift and arrow keys

I just test marktext, and marktext also unable to select soft-lines with Shift and arrow keys? but marktext can use arrow keys to move between soft lines, and muya can not, I think this is a bug.

[Ran Luo]

Block backport of marktext/marktext#2835 and marktext/marktext#2853, if needed.

If there is a similar problem after the selection all functions is implemented later, backport is required. I have been thinking about selecting all feature. The minimum granularity can only be in block units, that is to say, in the case of cross-blocks, blocks can no longer be selected. part of , can only choose all block content, or not? like Notion.

[Felix Häusler]

The minimum granularity can only be in block units, that is to say, in the case of cross-blocks, blocks can no longer be selected. part of , can only choose all block content, or not?

I don't really understand this. You mean that a user can only select text within a block or all blocks with "select all"?

I think this would be a bad design because editing and selecting text over multiple paragraphs is a core feature of an editor. How would you copy/cut/replace/delete multiple blocks? Multiple separated blocks seem to be a good idea for virtual rendering etc. Could we implement selecting internally that if the user selects an area, the selecting is done by our editor? We need an internal selection state that executes operations like text input, copy, cut, delete, etc. If you select a text starting from | in foo to | in bar, the editor could perform an operation and re-render the changed part.

f|oo

ba|r

Edit: I think Atom and VsCode do the same. They should have a contenteditable at the cursor position and forwards all input and events to the editor that handles the actions on the data structure. Afterwards, the changes are rendered.

[Ran Luo]

I don't really understand this. You mean that a user can only select text within a block or all blocks with "select all"?

Maybe my statement wasn't clear enough, for example, if you select a text from starting from | in foo to | in bar, it will select the two paragraphs, and highlight the two paragraphs, not only the oo\nbar, and not the whole document too.

<mark>f|oo

ba|r</mark>

zar

Another example, it will select the two list items if foo and bar are two list items in the same list.

<mark>- f|oo
- ba|r</mark>
- zar

We will find the nearest common ancestor of the two selection blocks(anchor block and focus block), and then select all blocks between these two blocks under this ancestor.

[Felix Häusler]

if you select a text from starting from | in foo to | in bar, it will select the two paragraphs, and highlight the two paragraphs, not only the oo\nbar, and not the whole document too.

I always wondered whether this behavior was expected in Notion and rather thought of a bug because it's not intuitive for a text editor. It feels very pain if you think about Office 365 or Google Docs, but you are restricted to edit only within a block/line. I would expect that many user would be unhappy with this change because editing will come more restricted. What's the core issue to forbid this? Why couldn't we update the page selection from the internal cursor that is counted forward/backwards on arrow key input and mouse movement?