#121 keep text file line endings as-is and play along with them

[bughunter2]

When editing a text file which has CR LF line endings, the CR character appears as an invisible character which does take up space, just like a space character. When we save the file, those CR characters are lost and converted to spaces.

If we add text to an existing file using the editor, they always use LF line endings.

It would be nice if Ghost Commander respected line endings, and played along with them.

So ideally, Ghost Commander should: Preserve line endings. Use the same style of line endings that the existing file uses. Never mix them. A file which has CR LF line endings should still use CR LF line endings after adding more text to it with Ghost Commander. The same goes for files with only LF line endings, or only CR line endings.

However, for now, perhaps a simpler solution to deal with files that have CR LF line endings, is to simply remove CR characters instead of converting them to a space.

Note, at the moment, Ghost Commander does NOT support text files with only CR line endings. Vim calls this Mac line endings, as previous versions of Mac OS used it, before Mac OS was renamed to macOS. Ideally, Ghost Commander would support those too, in the same way as outlined above (preserving, and playing along).

This behavior has existed for years. It's not a new regression.

[zc2]

Thank you for suggestion. It's been implemented as follows:
If a file contains a CR (even a single one), all LFs would be replaced with CRLF during the file saving. Please give a try:
https://sourceforge.net/projects/ghostcommander/files/Betas/Ghost%20Commander%201.64.2b3.apk/download

[bughunter2]

Thanks for taking the time to look into this.

I've tested the .apk you referred to.

After opening it with the Ghost Commander editor and simply clicking Save, I get the following results.

For old Mac-style text files: It seems that files with only CR line endings (old Mac style) lose their EOF line ending, and if we have a sequence with two empty lines, they get compressed into a single new line. I'm not too worried about such text files, as they are rare. But I'll let you be the judge.

For text files with Unix-style or Windows-style line endings: they seem to be preserved correctly now. The MD5 hashes are identical before and after the test.

Here's a test I just performed with the new app version you referred to.

I simply created the following text file on a PC using Vim, and saved it in 3 different types of line endings (Mac, Unix, Windows).
Then, I simply opened them using the Ghost Commander editor and saved them. Then I looked at them with both a text editor and a hex editor.

START OF TEXT FILE:

hello, world

this is a test

END OF TEXT FILE.

See the below/after comparison below.

Before opening and saving:

$ for i in txt*; do echo "> Contents of: $i"; hexdump -C "$i"; echo ---; done
> Contents of: txtmac.txt
00000000  68 65 6c 6c 6f 2c 20 77  6f 72 6c 64 0d 0d 74 68  |hello, world..th|
00000010  69 73 20 69 73 20 61 20  74 65 73 74 0d           |is is a test.|
0000001d
---
> Contents of: txtunix.txt
00000000  68 65 6c 6c 6f 2c 20 77  6f 72 6c 64 0a 0a 74 68  |hello, world..th|
00000010  69 73 20 69 73 20 61 20  74 65 73 74 0a           |is is a test.|
0000001d
---
> Contents of: txtwin.txt
00000000  68 65 6c 6c 6f 2c 20 77  6f 72 6c 64 0d 0a 0d 0a  |hello, world....|
00000010  74 68 69 73 20 69 73 20  61 20 74 65 73 74 0d 0a  |this is a test..|
00000020
---

After:

$ for i in txt*; do echo "> Contents of: $i"; hexdump -C "$i"; echo ---; done
> Contents of: txtmac.txt
00000000  68 65 6c 6c 6f 2c 20 77  6f 72 6c 64 0d 74 68 69  |hello, world.thi|
00000010  73 20 69 73 20 61 20 74  65 73 74                 |s is a test|
0000001b
---
> Contents of: txtunix.txt
00000000  68 65 6c 6c 6f 2c 20 77  6f 72 6c 64 0a 0a 74 68  |hello, world..th|
00000010  69 73 20 69 73 20 61 20  74 65 73 74 0a           |is is a test.|
0000001d
---
> Contents of: txtwin.txt
00000000  68 65 6c 6c 6f 2c 20 77  6f 72 6c 64 0d 0a 0d 0a  |hello, world....|
00000010  74 68 69 73 20 69 73 20  61 20 74 65 73 74 0d 0a  |this is a test..|
00000020
---

[zc2]

Thank you for testing. I chose not to support the old Mac types. Instead I've added an option to override the CR presence found during the loading, so the user can now load a Unix file and save as Windows or do the opposite. Here is an apk for testing:
https://sourceforge.net/projects/ghostcommander/files/Betas/Ghost%20Commander%201.64.2b4.apk/download

[bughunter2]

I've tested it and it works well. It's a sensible implementation. Cheers!

[zc2]

thank you