Undo affects Line Endings

[ProgerXP]

trafficstars

Not sure if we can fix this as it might be Scintilla's issue.

1. Open a new window, set it to LF
2. Enter two lines, e.g. a, Enter, a
3. Copy everything (Alt+C) and paste into a cmd.exe window (using it as an example because it doesn't recognize LF and puts everything on a single line) - you should get aa on one line (not as two different commands)
4. Change to CR/LF (double click in the status bar)
5. Repeat step 3 - you should get a executed and then a entered (so, 2 lines were pasted)
6. Press Ctrl+Z, then repeat - you will see that even though the status bar still says CR/LF, in fact line breaks are pasted as LF as indicated by cmd.exe accepting aa instead of a + a

[cshnik]

Please consider the following:

1. Switching of the EOL mode is made in two steps: I. Modification of the internal EOL flag (SCI_SETEOLMODE message). II. Applying the EOL flag (SCI_CONVERTEOLS message). This operation updates document content and causes history update: text modification is stored as a set of DeleteChars/InsertChars commands.
2. Undo() command will apply these commands in reverse to make proper text rollback. However, Undo() does not affect the internal EOL flag.

There are 2 problems here:

1. EOL mode displayed in the status bar is incorrect (does not match the actual EOL in the binary content) after applying Undo(). The simple and clear fix would be to retrieve EOL flag from Scintilla (SCI_GETEOLMODE message) and update status bar. But this will not work due to the problem 2.
2. Scintilla is not updating it's internal EOL flag when undoing the changes related to previously applied EOL switch (CR/LF/CR+LF).

At this point it seems difficult to fix this behavior in Scintilla.

[ProgerXP]

Scintilla is not updating it's internal EOL flag when undoing the changes related to previously applied EOL switch (CR/LF/CR+LF).

If this is a Scintilla's issue then can we report it to them and see if they will fix it like they have fixed #116?

[cshnik]

I was able to reproduce the same behavior using SciTE 4.2.0 (Jul 5 2019). However, in this tool EOL mode is splitted up into 2 different menu commands:

1. "Line End Characters" menu option: CR+LF/CR/LF (select EOL mode)
2. "Convert Line End Characters" menu command (apply EOL mode to content) Status bar display the currently selected EOL mode which does not actually refer to the editor contents.

It looks like EOL mode is not an option which was designed to be internally controlled by Scintilla after loading of file contents (e.g when applying/undoing changes).

[ProgerXP]

I was able to reproduce the same behavior using SciTE 4.2.0 (Jul 5 2019).

And the same thing happens in Notepad++. Which just like Notepad2 has only 1 setting for toggling line breaks, not 2.

I think we should still report this to Scintilla because Notepad++ is a very popular editor and so we have 2 editors using this flag/mode to convert between line break styles. If this is a wrong way to convert then they should suggest some other way.

[cshnik]

I made few additional tests and found specified behavior is expected. Please consider the following:

1. Enable "Show Line Endings" option (Ctrl+Shift+9) and repeat all the steps.
2. Now it becomes clear selected EOL mode in Notepad2e does not refer the actual file contents (the same for SciTE and Notepad++) when utilizing Undo/Redo. This also explains why EOL in status bar never changed on Ctrl+Z/Ctrl+Y.
3. Regarding the Ctrl+Z in step 6: it works as expected since EOL switch from LF to CRLF was made in 2 double clicks: LF>CR>CRLF. First Ctrl+Z will rollback text content from CRLF to CR which give stated result.