On Jun 7, 2014 1:47 PM, <to...@acm.org> wrote: > > Well, I can give a couple of personal examples that you easily try yourselves: > > * Windows side: Copy/Paste in Windows can not deal with LF endings correctly. Example: PNotepad editor in Windows loads Linux files but copy-pasting from it (for example) to other apps messes up all text (puts it all in a single line).
Yes, though this is more a deficiency with a particular program than with Windows at large. The fact is that the convention of "newline only as EOL marker" is just a convention. CRLF is arguably more correct, particularly given the era in which it was established. > * Linux side (vi): Have you tried editing a Windows text file under vi? It shows all ^M (CRs) at the end of each line. I have, and agree it is annoying, but that is an issue of vi choosing not to handle alien text file formats. > * Several old time assemblers will choke on wrong line endings. Their binaries cannot be updated as the source is no longer available. So, you must edit code only in the right format or you’re out of luck. This seems to be conflating the editing of assembly source with editing of binaries for which source is no longer available. What am I missing? > I also wrongly assumed the guys who maintain Git saw a reason for having this option. I can promise you it wasn’t me who asked for it, so they must have had nothing better to do than to add a useless feature in their app that nobody ever needs. Now this is maybe a slightly emotional response. No one has told you EOL conversion is a useless feature, just that in their opinion that it doesn't belong in a particular DVCS whose primary overriding concern is "store what I tell you to store exactly as I have stored it". To me this makes sense, particularly on a platform (unixen) that is notorious (to a fault maybe?) of advocating tools do one thing and do it well. I agree that there are tools that will "do the wrong thing" with mixed or alien EOL markers. My bread and butter is provided primarily by Windows development, so I have to use Visual Studio extensively. It detects mixed line endings on open and offers to normalize. Perhaps an email to vi or emacs or [insert editor of choice] devs might convince them to change their tools. :) I think one of two potential solutions are possible here though: 1. Convince the devs to support hooks (which have their own issues as argued in the past), particularly pre/post commit and post update hooks. In this way tooling (such as tr or dos2unix/unix2dos) could be made to normalize line endings after changes. 2. In the absence of hooks, relatively simple shell scripts could do the exact same thing. SDR
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
