Could someone explain the significance of the following please.
Files in Notepad++ show CR and LF as distinct characters. But TextPad shows CR and CRLF the same, as one symbol. So I would not see the distinction while editing in TextPad.
This arose when editing .M3U playlist files, when I noticed in Notepad++ that some entries ended with CR and other with CRLF. I'm unclear what if any relevance this might have on the behaviour of the files in a music player. I'll test, but would appreciate some insight into this topic please.
--
Terry, East Grinstead, UK
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would assume its just due to how the editor decides to implements it. Notepad++ is showing the symbols for each byte, that is why it is showing CR and LF separately. I'm not familiar with TextPad but its probably not concerned about what the characters actually are, its just displaying where the end of the line is for the user.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, I'm sure you're right. But it raises the side issue of what sort of text file is saved by Notepad++ if I delete all occurrences of LF? In TextPad the result looks just the same. I can display it. I can Print it. Is the LF byte redundant?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Notepad++ doesn't change the line endings when saved. So whatever bytes are displayed are exactly how it will get saved. Most modern text editors (e.g. Notepad++, TextPad, etc) are able to handle all types of line endings. The main issue is if you have another program that has to read text files, in your case the .M3U files, and it expects a specific type of line ending, then the file must be saved that way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In a further test with a mix of five playlists in my car player, I had a more puzzling result than I reported earlier. All three of the 'CRCF' types played OK, but one of the two 'CR' types did not. I had edited in both Notepad++ and TextPad (my version is old) so t may be that some other attribute distinction muddied the water. (That BOM stuff, for example, a topic I've never grasped!)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could someone explain the significance of the following please.
Files in Notepad++ show CR and LF as distinct characters. But TextPad shows CR and CRLF the same, as one symbol. So I would not see the distinction while editing in TextPad.
https://dl.dropboxusercontent.com/u/4019461/CRLF-Different%20Display.jpg
This arose when editing .M3U playlist files, when I noticed in Notepad++ that some entries ended with CR and other with CRLF. I'm unclear what if any relevance this might have on the behaviour of the files in a music player. I'll test, but would appreciate some insight into this topic please.
--
Terry, East Grinstead, UK
I would assume its just due to how the editor decides to implements it. Notepad++ is showing the symbols for each byte, that is why it is showing CR and LF separately. I'm not familiar with TextPad but its probably not concerned about what the characters actually are, its just displaying where the end of the line is for the user.
Thanks, I'm sure you're right. But it raises the side issue of what sort of text file is saved by Notepad++ if I delete all occurrences of LF? In TextPad the result looks just the same. I can display it. I can Print it. Is the LF byte redundant?
Notepad++ doesn't change the line endings when saved. So whatever bytes are displayed are exactly how it will get saved. Most modern text editors (e.g. Notepad++, TextPad, etc) are able to handle all types of line endings. The main issue is if you have another program that has to read text files, in your case the .M3U files, and it expects a specific type of line ending, then the file must be saved that way.
Thanks, understood. From initial tests, the players I tried both seem happy with endings of either CR or CRLF.
The problem is that "newline" is not a fixed character and different systems have traditionally used different bytes/byte sequences to represent it.
Windows: CR LF
Unix (including Mac OS X): LF
Mac OS before X: CR
As you have discovered, many programs can deal with all of these formats.
Notepad++ chooses to faithfully display the actual bytes and not amalgamate them into one fictional "newline" character.
http://en.wikipedia.org/wiki/CR_LF#Representations
Thanks Andreas, understood.
In a further test with a mix of five playlists in my car player, I had a more puzzling result than I reported earlier. All three of the 'CRCF' types played OK, but one of the two 'CR' types did not. I had edited in both Notepad++ and TextPad (my version is old) so t may be that some other attribute distinction muddied the water. (That BOM stuff, for example, a topic I've never grasped!)