Line endings
Posted by map Wed, 24 May 2006 21:16:00 GMT
Today a user asked me why SubEthaEdit now tries to warn you if you accidently create a file with mixed line endings. I figured it might be a good idea to explain that feature and the underlying issue here.
Line endings are used to mark the places in a text file where (surprise) a line ends. Unfortunately many different ways to do that evolved in the history of text editing dating back as far as 1963 according to Wikipedia. Mac OS 9 and lower used a invisible character called "carriage return" or CR for short, while Unix variants (like e.g. Mac OS X) use a "line feed" (LF). Microsoft flavored operating systems tend to use a carriage return followed by a line feed (CRLF). SubEthaEdit of course supports all of these and additionally rarely used Unicode characters called LSEP and PSEP. As a tip, if you feel unsure about which line ending to use, I'd recommend sticking to LF or, in case your text will also be edited on Windows, to CRLF.
Usually these opposing standards don't cause major problems anymore as most modern applications and utilities can deal with at least LF and CRLF. One situation that can still cause major mayhem however, is the case of mixed line endings. If you copy and paste to your text from various sources for example, it can happen that some of these copied lines are ended with a CR, some with a CRLF and others with LF. Quite a few applications and utilities can be very confused by these mixed endings, leading to malfunctions or crashes.
Therefore SubEthaEdit 2.5 tries to help you to be consistent with your line endings. E.g. upon paste it will offer to convert the line endings of the pasted text to your current preference. If you open a file with mixed endings SubEthaEdit will present you with an option to convert the endings to the most prevalent endings. Additionally, SubEthaEdit will alert you about line endings in your text that don't match your preference by showing the character representing the invisible CR or LF in red.
We hope this new functionality can contribute to making the world a less confusing place, even if it's just the world of text files and text processing… ;)
PS: Don't forget, May 25th is towel day.
I have been sort of wishing that you would stop calling CR line endings "Mac" and LF line endings "Unix". It seems like CR as a line ending is really more appropriate to be called "Classic Mac" or "Mac OS 9", and that LF could be called "Unix/Mac OS X".
Hi, this is really a nice feature. Some times ago i had problems with wrong line-endings, which caused some scripts not to work. De-Bugging this by hand within another system-native editor took a lot of time. I think, these little features are a big plus. Keep up the good work!
You are right Dan. I will file that as a bug.
@dan: yeah - we will change that. Although we took the original wording from Xcode so you'd probably should file a bug there too ;) (I just checked, they still call it Mac in 2.3)
I love this new feature. I am forever pasting in text and then forgetting to convert the line endings before I save. Thanks for a great product guys!
The real question is: should anyone ever want to create such a mixed line ending file? It would feel much more natural to simply convert the pasted text to the current line ending without a dialog, since this is highly likely what the user wants.
Yes there are cases in which mixed line endings have to be supported. E.g. Database dumps, or other text-formats that use one line ending for separation of date and one line ending for the actual line ending in the data.
One might argue that there are cases where you would want mixed line endings, e.g. storing text that is CRLF in a LFed XML's CDATA section. (And yes, I have seen these in real life.)
Aside from obscure examples, I'd argue that it's better to allow for the freedom of choice when in doubt. It might however be a good idea to have a prefence that let's you specify to delegate these decisions to SubEthaEdit completely.
perhaps then a preference to disable/enable the dialog box and auto convert the line endings? and perhpas it should default to disable the dialog box? so far i've never had to edit a file with mixed line endings, so the warnings are a bit anonying (but good to know too.) keep up the good work!
Wow, this is probably the finest release to date, I just purchased licence few days back -- SEE is by far the nicest editor on OS X ;)
Here's the quote from post I wrote on Cocoaforge:
"Heeeey people, SubEthaEdit is probably my most loved app, and I don't even use that collaborative stuff at the moment.
It's the most beautiful text editor in the world :) They take UI very seriously and follow HIG religiously, everything is carefully put together. And only because of that, I'm kinda most comfortable to work in it. Secondly, I'm not so hard core about text editing (like BBEdit or TextMate), so I find it more than adequate for me. Don't get me wrong, SEE is packed with good features, but it's also very lean and mean, so small and lightweight, I just love it! And BTW, I think that SEE back-end is also very nice when they managed to cram all that nice stuff in such size, probably because they know Objective-C well...
So, to put it in this way: I wouldn't be so happy if they start to put more and more features (or big UI changes) in it just for the sake of it, I don't want it to become yet another bloated text editor. In fact, I would be very angry."
So, keep up the good work guys!
I think this is a crucial feature of this SubEthaEdit as it converts the line endings to the current preference. This is not at all confusing for me.
mixed line ending result in subversion difficulties. though it is bit ennoying to see the warning but still it is useful. good work. thanks StellaClark
mixed line ending has always been a problem for me in running the software.i have encountered many difficulties in subversion with mixed line endings. this feature of subethaedit is really helpful for me.
i need ine words