Mr. Silli: You are jumping on a bandwagon that has a broken wheel. Do not presume that Mr. Wilson’s description of the line-ending actions of XXE is accurate.
I manage a thousand-page doc set composed of over 1200 Subversion-hosted DocBook files. I edit these files using XXE on a Mac, XXE on Windows, Oxygen on Mac and Windows, plus vi, sed, perl, and whatever other tools are required. All of these tools interoperate without changing line endings back and forth. This is standard practice at many sites all over the world. XXE does NOT impose non-standard line endings on our files. Mr. Wilson: The XML editor you are looking for is Oxygen; see oxygenxml.com <http://oxygenxml.com/>. Perhaps after you purchase your Oxygen license, you could move the weight and gravity of your expertise over to one of their forums. And. not. here. > 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
-- XMLmind XML Editor Support List xmleditor-support@xmlmind.com http://www.xmlmind.com/mailman/listinfo/xmleditor-support
