Skip to content
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

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

thisiswhereitype
Copy link

@thisiswhereitype thisiswhereitype commented May 3, 2024

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.

@bollwyvl
Copy link
Contributor

bollwyvl commented May 3, 2024

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:

    --unix-line-endings
        Write text files with UNIX LF line endings:      \n
    --windows-line-endings  
        Write text files with Windows CRLF line endings: \r\n

@bollwyvl
Copy link
Contributor

bollwyvl commented May 3, 2024

In addition to reading, being able to force writing with a newline variant would be fantastic.

@thisiswhereitype
Copy link
Author

thisiswhereitype commented May 4, 2024

In addition to reading, being able to force writing with a newline variant would be fantastic.

Thanks for the feedback - open as linked above handles reading and writing depending on the file pointer mode arg. The docs provide a bullet point for the treatment under r/w. This arugment is illegal in mode='b' (binary).

The --newline is only passed to the output via the Writer class so as of writing this PR only affects writing.

Reading text is universal mode where all line endings are normalised to \n by default. This line appears to be reading is done.

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 LF to satisfy the discussion, this has been adopted by VScode Jupyter .

@thisiswhereitype thisiswhereitype marked this pull request as ready for review May 12, 2024 14:49
@thisiswhereitype
Copy link
Author

thisiswhereitype commented May 12, 2024

The interface is not using repr as the docs are rendering newlines:

--use-crlf-newline
    Implies CLRF newline.
    Equivalent to: [--NbConvertApp.newline=
    ]
--use-lf-newline
    Implies LF newline.
    Equivalent to: [--NbConvertApp.newline=
    ]

@thisiswhereitype
Copy link
Author

Reset bad author on commits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

nbconvert to notebook doesn't respect line endings
2 participants