Test case 1.
1. Save following with text as a text file with Unix lines:
Code: Select all
2020-09-09 16:40:18 Low memory clear event!
2020-09-09 16:40:18 Low memory clear event!
2020-09-09 16:41:30 tcApplication: onCreate
2020-09-09 16:41:35 PlayIntentReceiver.onReceive: com.ghisler.PlayPause
2020-09-09 16:41:35 showPlayerNotificationIfNotVisible
3. Open "Edit comment" (Ctrl+Z) dialog for some file.
4. Save the comment with F2:
the comment will be saved with Windows linebreaks.
5. Open this comments dialog again, select all and past the text again instead of current comment (or past it as a new comment for some another file).
6.Don't save comment now, but with Enter key, manually create the linebreaks in places where Unix linebreaks should exist (Edit Comments dialog show them as an invisible character, though you can disover them by need of additional move of caret "|" with cursor keys).
7. Now save the comment.
The comment will have 2 Windows linebreaks now in places where original Unix linebreaks existed.
8. Maybe some side bug or so, would be nice if somewone will confirm it. If to repeat steps 5-7 for the same comment many times, sometimes for some line TC saves the single linebreaks, so saved comment may have a look like this:
Code: Select all
2020-09-09 16:40:18 Low memory clear event!
2020-09-09 16:40:18 Low memory clear event!
2020-09-09 16:41:30 tcApplication: onCreate
2020-09-09 16:41:35 PlayIntentReceiver.onReceive: com.ghisler.PlayPause
2020-09-09 16:41:35 showPlayerNotificationIfNotVisible
Do the same steps 1-7 for following text saved with Unix linebreaks:
Code: Select all
2020-09-09 16:30:41 =====================================
2020-09-09 16:30:41 MediaPlayerActivity: onCreate
2020-09-09 16:30:41 Low memory clear event!
2020-09-09 16:30:41 MediaPlayerActivity:onResume
2020-09-09 16:30:41 MediaPlayerActivity: onWindowFocusChanged (hasFocus)
2020-09-09 16:30:41 MediaPlayerActivity: adjustPlayerWindow: w=0, h=0, windowh=0
2020-09-09 16:30:41 MediaPlayerActivity: onResizeListener
- In step, 4 the comment will be saved with visible "\n" text instead of any kind of new lines.
The tooltip for the comment will also show the "\n" text instead of actual linebreaks.
- In step, 7 the comment will be saved with visible "\n\n" text instead of any kind of new lines.
The tooltip for the comment will also show the "\n\n" text instead of actual linebreaks.
Obviously, if invisible linebreak would get autoconverted either to Windows linebreak or to "\n" sequence when the text is pasted, there would be no intention to create the lines in the Edit Comment dialog manually, which leads to unexpected and unpredictable result.
I reported about that unexpected behavior of Edit Comment editbox in September, 2020 by email (at that time I also didn't know that sometimes comments with Unix lines could be saved with "\n" as in a test case 2), but Christian just explained the reasons of curren behavior which I think is unexpected:
P.S. Alsthough in TC 10 beta 1/1a there is a change in the copying of the text with Unix lines form Lister, it doesn't seem to have any impact on results of reproduce steps above.Christian Ghisler by email wrote:This happens because the text file is in Unix/Linux format, and Notepad doesn't convert it to Windows line breaks (CR/LF) when copying to the clipboard. The regular edit box of the comment field does not support Unix line breaks.
Edit: My configuration:
Windows 7 32-bit SP1 Russian;
Total Commander settings for comments:
Comment type: descript.ion
Preferred type: "Plain text+UTF-16"
"DOS Charset" - tested with enabled and disabled, doesn't seem to make any impact both for existing and new comments woth test text examples.
In Edit Comment dialog: "Use OEM (DOS) font" checkbox is unchecked.