- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Thu, 02 Nov 2023 08:24:38 +0000
- To: Dimitre Novatchev <dnovatchev@gmail.com>
- Cc: Christian Grün <cg@basex.org>, public-xslt-40@w3.org
- Message-ID: <m2lebgh7vq.fsf@saxonica.com>
Dimitre Novatchev <dnovatchev@gmail.com> writes: > All this is better be completely prevented/eliminated and made "invisible" to Windows users - and > this is, per my understanding, what Norm has done. Thank you Norm. You’re welcome. But I think what Christian is saying is that if we just fixed the line endings as Unix style, Windows programs would all cope. In other words, if you open a file with Unix style line endings in your favorite Windows editor, “it just works”, you can’t tell (or if you can tell, you don’t have to care). I think this is the case. If the file you save from your editor uses Windows line endings, they’ll be automatically converted to Unix line endings when you commit the file. The problem is equally solved this way, I think. I can see only two differences between the approaches: 1. Currently, the files are “binary” different. Getting a repository as a ZIP file or downloading the “raw” files from GitHub’s UI will save Unix line endings even on your PC, but the way I’ve currently configured .gitattributes, the files you check out on your Windows PC will have Windows line endings. 2. If we switched to fixed Unix line endings, and someone’s favorite Windows editor can’t cope, that’d be inconvenient. But there’s at least the assertion that modern editing tools on Windows can all cope with Unix style line endings so case 2 doesn’t apply. Be seeing you, norm -- Norm Tovey-Walsh Saxonica
Received on Thursday, 2 November 2023 08:33:42 UTC