While editing a paragraph in one of my articles, I accidentally selected the entire final paragraph and then continued typing, thus overwriting the entire paragraph. When I attempted to "undo" (using Ctrl+Z) as usual, the command failed, resulting in the permanent loss of the paragraph. I had previously used the undo command successfully, and I also subsequently used it successfully. But something that I had done in that moment "broke" the undo command, causing it to lose its previous "memory" of my edits (including the text of the missing paragraph).   From my subsequent testing, I have identified a common thread that consistently replicates this bug: making edits that involve line breaks and paragraph breaks, or that involve the very end of the document/section. The details are a little complicated, but are described in the Steps to Replicate section below.   A slightly different form of the bug can be replicated by using "Backspace" on a selection of text or by "pasting" text into an article (Ctrl+V). This doesn't break the "undo" chain like the other methods, but these actions themselves cannot be undone.   These forms of the bug only occur in the normal editor mode, not "source mode" (or this report form). However, I did discover an additional method of replicating the bug that only applies to source mode (and this form): using any formatting command or clicking any formatting button that adds BBCode (such as pressing the "bold" button in the editor or using Ctrl+B here).   SPECULATION AS TO UNDERLYING CAUSE: My gut from my testing is that the "line/paragraph break" problems and the "BBCode in source mode" problem might be related to each other. If line breaks and paragraph breaks are handled similarly to BBCode "under the hood" (which using Ctrl+P in source mode suggests is perhaps the case), then maybe the same bug the breaks the "undo" chain for BBCode commands in Source Mode also breaks the "undo" chain for line and paragraph breaks in "normal" mode?   ***************************************** PERSONAL NOTE: If I can be honest (and a little verbose) for a moment: I've been considering getting a World Anvil guild membership for a while because I do genuinely like the platform and want to support the goal of helping people build and share their worlds more effectively. But this recurring bug that can erase (and for me on more than one occasion has erased) significant chunks of writing in one fell and irreversible swoop... well it's given me SERIOUS pause about doing that... and honestly even about continuing to use World Anvil as a primary platform at all. And, to be honest... the fact that I know I've reported this bug before, long enough ago that I can't even see that report anymore... is kind of disheartening.   Having tried out the Euclid editor a bit, it seems like it doesn't suffer from any of these issues, which is encouraging! I think I'll be using that as my primary editor going forward, since I don't mind losing the WYSIWYG element. But with Plato as the "default" editor, I think some serious troubleshooting needs to be done to fix these problems that could potentially cause new users to give up on the platform after one bad experience, or that could at least teach people the hard way that they need to use non-default settings in order to avoid losing potentially hours of work to bugs.

Steps to Reproduce

I've identified several ways to reproduce this bug. I've described each one in concise detail below. I've also reported a couple other things I noticed in my testing that seem like they might be relevant.   Adding Any Paragraph Break (1) Type some text, such that you can identify the effects of the "undo" command (then "redo" it). (2) Either hit Ctrl+P or click on the "new paragraph" button to add a paragraph break. (3) Attempt Ctrl+Z. This ALWAYS fails for me, breaking the "undo" chain entirely.     Overwriting a Selection of Text that Contains a Line Break with a New Line Break (1) Type some text including one or more line breaks (as created by the "Enter" key). (2) Select part of the text including one or more line breaks (either with Shift + Arrow keys or by dragging the mouse). (3) Hit "Enter" to overwrite the selected text with a new line break. (4) Attempt Ctrl+Z. This ALWAYS fails for me, breaking the "undo" chain entirely.   This also sometimes works with a selection including paragraph breaks instead of normal line breaks, but not as reliably. Other times, that seems to simply insert a new line break at the END of the selection, or even the end of the article. (This is similar to another consistent bug I've noticed, where adding line breaks in the middle of a paragraph inserts them at the end of that paragraph instead. I don't know if this is relevant... but given the fact that line breaks seem to be a key problem here... maybe?)     Overwriting a Selection of Text that Contains and is Bounded by Line Breaks with Anything (1) Add some text to an article (2) Hit "Enter" to create a line break. (3) Repeat that process until you have at least four lines of text separated by line breaks. (4) Select the entirety of lines 2-3. (5) Type anything, overwriting lines 2-3. (6) Attempt Ctrl+Z. This ALWAYS fails for me, breaking the "undo" chain entirely and starting a new one with the newly typed text from (5).   This also works if you use the end of the document as one of the "boundaries", i.e. if you omit the 4th line of text in this example. But if you don't select at least one line break and ALL the text on the lines, the bug fails to occur.     Overwrite the Entirety of the Document, Regardless of Line Breaks (1) Type any amount of text, with or without paragraph or line breaks. (2) Select the entire text field. (3) Type anything else, overwriting the entire document. (4) Attempt Ctrl+Z. This ALWAYS fails for me, breaking the "undo" chain entirely and starting a new one with the newly typed text from (3).   So yeah, this one is a BIG DEAL. Any bug with the potential to irreversibly delete an entire article (or at least an entire section within an article) is a MAJOR one.     Use "Backspace" on a Selection of Text (1) Write some text. (2) Select some of it, even just a single letter. (3) Hit "Backspace" to delete the selected text. (4) Attempt Ctrl+Z. This ALWAYS fails to restore the deleted text for me. However, it doesn't fully break the "undo" chain, as previous edits can still be undone to some extent (though often not ALL of them).   So this is also a pretty BIG DEAL. Some of the other examples in this list are fairly niche and are therefore going to be somewhat rare occurrences. Using "Backspace" to delete a selection of text is not. It's standard operating procedure! Granted, it's almost always done intentionally... but that intent often carries with it the expectation that it can be undone if you change your mind in a timely manner!     Pasting Text (1) Write some text. (2) Copy some text, either from the document or elsewhere. (3) Past the text into the editor, using either Ctrl+V or the right-click menu. (4) Attempt Ctrl+Z. This ALWAYS fails to undo the pasting of the text for me. However, it doesn't seem to break the rest of the "undo" chain much.   This is a much more minor problem, as deleting extra text is much easier than restoring text that was deleted by mistake. Still weird though, and maybe related in some way to the others?     Using a BBCode Command in Source Mode (1) Go into "source mode" (2) Write some text. (3) Use "Ctrl+B" or "Ctrl+U" or "Ctrl+P" or any other command or top bar button that inserts BBCode into the text. (4) Attempt Ctrl+Z. This ALWAYS fails for me, breaking the "undo" chain completely.   (Needless to say, switching back and forth between "source mode" and "normal mode" also breaks the "undo" chain, but I'm assuming that's intended or at least unavoidable behavior.)   I'm speculating that this bug might actually be responsible for some of the other versions of the bug IF things like new paragraphs and line breaks are treated like BBCode under the hood (but aren't actually     Adding an "Actual" Line Break with Shift+Enter (1) Write some text. (2) Hit "Shift+Enter" or click the button on the top bar to add an "official" line break, represented by a red bracketed "[ br ]" in the text but no actual visible line break. If text was selected, it will still be there, and the break will be added at the front of it. (3) Attempt Ctrl+Z. This ALWAYS fails to remove the "[ br ]" line break for me. However, it doesn't always break the "undo" chain, at least not in its entirety.   So I hadn't realized at first that using "Enter" was not technically a line break, while "Shift+Enter" is. This seems likely to be the cause of some weird behavior of "Enter" I'd noticed unrelated to this bug. But related to this bug... I think this might be possible evidence of an underlying cause. If the paragraph breaks and actual "official" line breaks are both treated as something like BBCode... then perhaps the BBCode glitch is somehow related to these line break/paragraph break glitches?   Though in that case it'd be strange that normal formatting like "bold" or "italics" doesn't cause the bug.     Using "Undo" Doesn't Remove "Enter" Line Breaks (1) Type some text. (2) Hit "Enter" to add a new line. (3) Repeat that process a few times. (4) Hold down Ctrl+Z. For me, this DOES successfully undo the typed text, but NOT the lines added from enter... (5) Hit Ctrl+A to select all the text in the field. For me, each new line added with "Enter" will STILL BE THERE.   Noting this because it's strikingly similar to the behavior of the "Shift+Enter" line break version, suggesting a possible link to the bug. This isn't reproducible with Paragraph Breaks, as those just break the "undo" chain entirely.   Paragraph Breaks Added in "Normal Mode" are Missing in "Source Mode" and Lost Upon Returning (1) Write some text in "normal mode" (2) Add some paragraph breaks (Ctrl+P or the button) (3) Switch to "source mode". Note the absence of the paragraph breaks. (4) Switch back to "normal mode". Note the continued absence of the paragraph breaks. (5) For comparison, switch back to "source mode". (6) Add some paragraph breaks. Note the addition of BBCode "[ p ]" and "[ /p ]" brackets. (7) Switch back to "normal mode". Note the persistence of the new paragraph breaks (8) Switch back to "source mode". Note the continued persistence of the new paragraph breaks.   Noting this because it seems like it may be relevant to the question of whether line and paragraph breaks are messing with underlying BBCode and breaking the "undo" chain for the same reason that "source mode" BBCode commands do.