On 11/29/2015 5:44 PM, Leif Halvard Silli wrote:
... But the fact that XMLmind will, upon opening the checked out
file, reconvert the CRLF to LF, does not sound extremely
problematic ...
Oh, but it is!!!! (Nothing ever /sounds/ problematic. But it always is.)
Read this the following... and this is only the tip of the iceberg:
http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
What a mess. Add to that the fact that JGit (used in Eclipse' EGit
implementation) still doesn't support .gitattributes.
I have different developers, authors, and translators on different
platforms. The last thing I need is for them to be wondering why Git
(after I train them to use Git) is giving them warnings about
translating LF to CRLF when it goes into the local repository (and then
back to LF when it goes to the remote repository). And this is assuming
all the Git tools in the pipeline support autocrlf and/or .gitattributes
sufficiently to do the correct translations. Which they probably won't.
The last thing I need is for my new tool not to put out the correct EOL
for my platform.
Is using System.getProperty("line.separator") really that hard? Why does
XXE insist in doing things that are against accept best practices and
standard protocol (for decades now)? Is it really, really that hard? Why
should I change my workflow just because some developer couldn't be
bothered to do it the right way? It's just a single line! It's no
mystery! This has been here since Java 1.0 I believe...
Garret
P.S. My rants are free! No charge! Just send me more questions and I'll
give you more. :D ;)
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
