`write_text` has hardcoded line-ending `\n` - should be OS specific

[ckolumbus]

when using doorstop within a development project we have everything is set to autocrlf=true. On windows this leads to crlf as line ending and on linux only lf. autocrlf takes care of proper line ending the the working copy.

doorstop is hardcoded to lf only in common.py:write_text function. This should use the OS dependent os.linesep by default to avoid different line ending encodings in repositories.

Additionally: this could be made configurable, but the end parameter to the write_text function is never used anyway. Maybe this could be adjusted, too.

Opinions? Feedback?

[jacebrowning]

How should line endings be handled when there is a mix of operating systems among contributors to a particular Doorstop project? Shouldn't doorstop write consistent line endings and Git be configured to handle that?

[ckolumbus]

@jacebrowning git has already support for this (stupid) situation, check this for some more information. when doorstop tries to do it by itself, the git needs to be configured to specifically ignore its own mechanism for this files.

So my preferred solution would be to have OS specific line endings and have git handle the conversion when working across OSes.

BTW: cross-OS development happens more often nowadays. I'm a heavy user of DevContainers inside VSCode. So i have my git source code repo (with doorstop requirements) checked out natively on windows and inside DevContainers, which run Linux.

[jacebrowning]

So my preferred solution would be to have OS specific line endings and have git handle the conversion when working across OSes.

👍🏻

[ckolumbus]

I can implement the solution, but what would you prefere

1. hardcoded "default" to OS line endings
2. configurable via document definition file

let me know, then I could make a PR

[jacebrowning]

@ckolumbus Let go with os.linesep wherever "\n" is used.

[JustinW80]

Reference to older issues about CRLF warnings: #310 , #480 .