On 30 Nov 2015, at 2:55, Garret Wilson wrote:
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/](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.
Reading the above page and your comments below, it is evident that
probablems could occur even if XXE on Window started to produce EOL as
CRLF. That document further signals that although current behavior might
have negative sideeffects (especially when Git is not optimally
configiured), it ought to be possible to live with XXE producing LF.
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...
Given how important/impractical the EOL issue somes is, it seems
possible that the XMLmind developers made a conscious choice to not
follow the Windows platform standard for a, potentially, defencible
reason. Even Git seems to favor LF and so does quite a few tools and
specs.
Btw, assuming that many cross platforms tools are made with Java and
thus that the Komodo editor is made with Java, then I can tell you that
I stopped considering Komodo because (at least back then) it was
adhering to "platform" standards too much (as in: defaulting to
macintosh text encoding rather than UTF-8).
Just my (almost free) 2 cents.
--
leif halvard silli
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
