Tim Bingham wrote: > > > I do my major editing with Emacs, or else I wouldn't be having > this problem. > > TICC canonicalizes line ends, while Emacs doesn't and can't be forced to > > (according to my reading of the docs, YMMV). > > OT: - emacs "does the right thing!" -
Back OT: what is the right thing? > - when creating a new file it uses the line ending convention of the host This is "the right thing". I don't think we could find any non-trolls to disagree with this. > - when modifying an existing file it accepts and preserves whatever line > ending convention the file already has Is this "the right thing"? In my case it is not. I have files which have mixed line endings. Preserving these is not, for me, A Good Thing. I would prefer IETF treatment - be liberal in what you accept, and strict in what you emit. I would rather see emacs canonicalize mixed line endings to the platform default, but not change the file unless it is saved. This implies that there is no good reason to have mixed line endings, which is probably true, but there's always the corner cases... But I'm shooting the messenger here. What shocked me was the discovery that CVS does not canonicalize line endings, but assumes that the platform default is in use. This has never been a valid assumption (can you say FTP? I try, but it just comes out "plltthhhh"), and we all know about "assume" anyway, yes? I'd call it a bug, but line ending behavior is fragile and should never be changed - it's not a bug, it's not a feature, it's just a fact. So what should I have done? Written wrapper scripts to call unix2dos on all text type files that get comitted. This may also require pre-invoking an editor for the commit comments so that unix2dos can be run on them as well, but it's not a bear of a script in any case. I'll keep it in the back of my mind and work on it as I am able. > If all programs obeyed these simple rules we'd be living in a more > perfect world. *SIGH* - everyone says that, but they've never got the same set of rules! ;-) /|/|ike _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs