-
Notifications
You must be signed in to change notification settings - Fork 568
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add eol --newline option for text content in nbconvert.writers.files #2145
base: main
Are you sure you want to change the base?
Conversation
This is a great feature. However, as your example shows, it might require complex shell escaping (windows is truly trash at that). Perhaps in addition to the explicit alias which accepts any-old-thing, add two flags:
|
In addition to reading, being able to force writing with a newline variant would be fantastic. |
Thanks for the feedback - The Reading text is universal mode where all line endings are normalised to We might expose an input flag so users can work with systems which have alternative EOL characters which aren't by default normalised, but I don't see that requested anywhere. NB: some comments in the issue thread point out the current behaviour "use-system eol" differs from the ecosystem. The default behaviours need deprecating in favour of use |
The interface is not using repr as the docs are rendering newlines:
|
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
e47308a
to
2a72e89
Compare
Reset bad author on commits |
closes #1062
Now users can specify the newline string to be passed to open for string data. This PR concerns writing.
This is fiddly requiring
--newline $'\r\n'
on Bash to force windows newline.However
--use-<crlf|lf>-newline
make this easier.The default, None, is to fall back onto
os.linesep
as currently used.I didn't look closely at tests but wanted to see what the CI makes of this.