Should this default be user definable? Cc @AndrewSouthpaw

That would ease some of what I mention above. Something like --line-ending-default or something, which we can fall back to (and not throw) in cases of mixed line endings.

Let's push configurable option to next minor.

I am not sure about how we should handle files with mixed endings. Perhaps we should do.

Thoughts @AndrewSouthpaw

Hmmm this could be a major change, as I mentioned here.

IMO it'd make sense for this to be behind a flag for v2, and change the default to automatically detect for v3.

For files with mixed line endings, I'm leaning towards throwing, because there's not really a reasonable thing to do. Whatever we choose, it could be the wrong behavior for the user, and quite subtle. We can give a flag for them to choose the override (below).

Printing a warning would be another option, but I'm generally a fan of failing fast, especially given that mixed line endings is probably an indication that something is weird and wrong about their file, and it'd be helpful for them to know about it.

Thoughts?

I agree #216 would be a major change especially as it uses the system default rather than detecting and it also re-writes the entire doc.

I think it would be ok if document is consistent use what is detected, otherwise use configured which has a default of '\n'.

This would mean:

• \n docs already with upto date toc would always use \n
• \r\n docs already with upto date toc would use config option with default \n. Can Result in mixed doc as per now if not configured otherwise.
• \r\n docs already with toc containing normalised line endings via script would use \r\n, changed behaviour. This would be low likelihood but what user wants as it removes need to add in a normalisation process. Effectively a bug fix.
• \r\n doc without toc would use \r\n, changed behaviour. In this case it is a change but avoids creating a mixed document which I see as a positive.
• \n doc without toc would use \n, no changed behaviour.

So we would only get a chance in a few scenarios. Let me know if you are on the same page.

Thinking about this some more, I feel we can merge this without the configurable default. That way this can be released as part of 2.4.1 due to it purely being a fix. This is because the only time a user would see a change is if they are post processing the toc to normalize the endings and all they would see is their processing would have no effect and for new docs we are avoiding introducing a line ending mismatch.

Hmmm this could be a major change, as I mentioned here.

IMO it'd make sense for this to be behind a flag for v2, and change the default to automatically detect for v3.

For files with mixed line endings, I'm leaning towards throwing, because there's not really a reasonable thing to do. Whatever we choose, it could be the wrong behavior for the user, and quite subtle. We can give a flag for them to choose the override (below).

Printing a warning would be another option, but I'm generally a fan of failing fast, especially given that mixed line endings is probably an indication that something is weird and wrong about their file, and it'd be helpful for them to know about it.

Thoughts?

That would ease some of what I mention above. Something like --line-ending-default or something, which we can fall back to (and not throw) in cases of mixed line endings.