Menu
▾
▴
#64 Strange behavior at Windows line endings
I'm using AlphaCocoa 9.0a10 on a 2014 MacBook Pro on MacOS 10.10.5.
When I'm working with Unix files (as indicated in the menu at the top left corner of the window), I have no troubles with the line endings. However, when I'm working with Win files, I get very strange behavior at the end of the lines. If I press Command-Right to get to the end of the line, the blinking cursor jumps to the right of the last character on the line, as expected. If I type a character there, it appears to the right of that last character and the cursor moves to the right to accommodate the new character. However, if I then press the right arrow key with no modifiers, the cursor does not seem to move. If I then type another character, the new character appears at the left end of a new line inserted for that character alone. If I then press the right arrow again, the cursor moves to the left end of the next line, as expected.
This behavior seems to indicate that AlphaCocoa is treating Windows' CRLF as two characters rather than a single newline character as AlphaX did. Selecting the invisible line-ending character in a Windows file and then choosing Word Count from the Tools menu bears this out.
However, the Regular Expressions help topic suggest the old AlphaX behavior of treating CRLF as a single character. Near the bottom of the file, I find "Note that a CRLF in text behave as a single line terminator, and will match a single . in a regular expression pattern." In fact, this is accurate. Searching for (?s). finds the full end-of-line character in both Unix files and Windows files.
The strategy in AlphaX was to convert all the line endings to CR and indeed all eols were thus treated as a single char: on saving the line endings were converted back to the original format. I certainly overlooked this issue in AlphaCocoa. Thanks for reporting. I'll fix this.
This is fixed now. Internally all line terminations are LFs upon opening, and they are converted to the specified type upon saving. This should be entirely transparent for the user: if a file with Windows endings is opened, the File popup displays Win as expected. But in the internal text storage, they are LFs.
Changes committed to the repository (rev. 1176). The core must be rebuilt.