Deletion of selected text deletes unselected text [bug]

[StructByLightning]

Description

Paragraphs of text disappear when deleting unrelated text. This happens constantly and is an incredibly obnoxious bug. I think there's multiple ways to cause it to happen, but this is the only one I was able to isolate.

Steps to reproduce

The left is MarkText, the right is gedit, a plain text file editor (to show you the exact contents of the file opened in MarkText).

Start with this. Note that the second "The" and the line starting with "door banged open" have a newline separating them, but not an empty line.

Then put your cursor at the start of the first "the" using the arrow keys (the bug still works with the cursor, but it's more reliable with the keys):

Press the down arrow to select the first two lines:

Press the backspace key:

Expected behavior:

I expected the line with "The" and the line with "e" to be deleted; that is, I expected the selected lines to be deleted.

Actual behavior:

The selected lines were deleted along with the line starting with "door banged". Note that the second "The" line did not get deleted.

Versions

• Mark Text: 0.16.1
• Operating system: Ubuntu 18.04

[brainchild0]

Confirmed (Version 16.2; Linux Mint 20).

Saved example text to document for download.

[brainchild0]

Possibly related to #1854.

[StructByLightning]

I noticed that if you switch to source mode and back to normal, the lines that were deleted but shouldn't have been reappear.

[stur86]

Any news on this? I still observe it in 16.3. It seems to me like the distinctive thing that causes the behaviour is deleting a selection across multiple paragraphs.

[tenbob]

I confirm this happens frequently on 0.16.3. Random chunks of text disappear without warning when you do some unrelated editing. As the OP said, this behaviour is quite obnoxious.

Unfortunately, this has undermined my confidence in the software. I can't work with an editor that randomly corrupts the document. It's really frustrating. I glimpse something changing on the screen and ask "WTF. What just happened?".

You can sometimes restore it by switching to source mode and back. But you're never quite sure it's exactly what it was before.

This should really be the number one priority to fix.

[stur86]

Agreed, this is truly a software breaking bug. Risking that any random editing will erase something else you might not realise has gone makes it incredibly dangerous to use.

[fxha]

Reference text:

The

e

The2
door banged open and a man strode in.

Given content contains two paragraphs and an additional one that contains also a soft-line (door banged open and a man strode in.).

Why is there a difference between mouse and keyboard?

The text selection is different using mouse or keyboard because the mouse will select the paragraph starting by The to e with offset 1. On the other hand the keyboard selection ends in paragraph The2 with offset 0. This can be reproduces in Firefox and Chromium and seems the expected HTML behavior.

Reproduce the issue with mouse selection:

The issue occurs with the mouse too by selecting more text in the The2 paragraph, like the first T.

Issue description:

tldr: All text removal across several paragraphs that end in a paragraph that contain soft-lines will lose all soft-lines because all text is discard after the first line-break.

Selecting text over several paragraphs that end in a paragraph with soft-line entries will result in a loss of all soft-lines in the ending paragraph because all text is removed after the (soft) line break (that is represended by a newline \n in MarkText).

Soft-line-breaks in MarkText:

Soft-lines are rendered in MarkText as separated text lines that are separated by a newline (.ag-soft-line-break) which contains \n. A user can now edited the different lines, add or remove soft-lines.

<span id="ag-101" class="ag-paragraph ag-active ag-paragraph-content">
  <span class="ag-plain-text">The2</span>
  <span class="ag-soft-line-break">\n</span>
  <span class="ag-plain-text">door banged open and a man strode in.</span>
</span>

The removal is correct if we remove the newline added by .ag-soft-line-break, but all soft-lines are merged into one paragraph (all soft-lines are gone). A very dumb workaround is to replace the newline via CSS, but in this case all soft-lines are converted into one big line that wouldn't be expected by the user. Maybe we can hack this to add a newline in Muya to keep the soft-lines.

I think we have to detect this case somehow and handle it manually without passing the removal event back to Chromium because Chromium will remove all content in the paragraph after the first newline/line break. @Jocs Some idea about a possible solution?

[tenbob]

Thanks for looking into this. The problem seems closely related to the way that MarkText works and what the "document content" actually means.

As I understand it, MarkText takes the user's markdown file and builds an internal model or DOM to represent it. All editing operations are done on the DOM itself without further reference to the original markdown.

The meta issue #2189 links together a number of separate issues that arise from this approach. Examples are reporting that things have changed when they haven't, unnecessary renumbering of lists and changing white space.

Instead of fixing these issues individually as special cases, would it be possible to alter the overall approach a little? That is, to define the document content as being the markdown itself, rather than the DOM that is derived from it. This would eliminate a lot of potential discrepancies between the two.

[brainchild0]

An abstract representation of the document, what you call a DOM, is the central engine of any software that edits or processes a structured document, such as one in Markdown. Eliminating it is not viable. In principle, however, an abstract representation may integrate with a representation of the original document, saving the original text in each node, or references to offsets in the original text, allowing a reconstruction of the original text for parts of the document not changed.

The difficulty is that most Markdown processing occurring today is in one direction, usually parsing Markdown text into an abstract representation used to generate a static rendering.

As an editor, MarkText processes in both directions, of parsing and storing, yet still depends on components principally designed for the more common case of parsing only.

Meeting the expectations of preserving as literally as possible the original document requires augmenting existing tools, which may not be easy, though I am not one familiar with the details.

I agree with the conclusion that various individually-reported issues are essentially manifestations of a single "meta issue", which is documented in the reference you provided. I think, though, an effective solution rests in augmenting, not eliminating, the abstract document representation.