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

Keep line-endings in ipynb #1663

Merged
merged 1 commit into from Jun 7, 2012
Merged

Keep line-endings in ipynb #1663

merged 1 commit into from Jun 7, 2012

Conversation

minrk
Copy link
Member

@minrk minrk commented Apr 25, 2012

Avoids discarding of information, e.g. foo\rbar should not be reconstructed as foo\nbar.

Implemented in safe manner, where notebooks written by old scheme will load the same as before, and be updated on next save.

Should address notebook loading issue brought up in #1659.

@minrk
Copy link
Member Author

minrk commented May 3, 2012

I should note that this will visibly affect people tracking notebooks in VCS, as it will append the newline character to every line of text/code cells after it is applied.

@Carreau
Copy link
Member

Carreau commented May 4, 2012

Well, this is a dev version, and from 0.12 to 0.13 you have a notebook conversion step ... so i don't think it will really be a problem.

@minrk
Copy link
Member Author

minrk commented May 4, 2012

I do not think it is a big deal, just making it clear what is involved. Also, there are definitely people using 0.13 notebooks in real work.

@ellisonbg
Copy link
Member

I think this looks fine. @minrk why don't you merge this unless you think there is something else you want to do.

@minrk
Copy link
Member Author

minrk commented Jun 7, 2012

I just thought of one more case where this will not be ideal, though I'm not sure we really care about it: it adds one more step to the downgrade-notebook gist, because v3 notebooks read by v2 (after manually decrementing the version) will get double newlines.

Shall I re-run the existing notebooks with this change? They will all get a 2-char diff on each line of multi-line cells.

@ellisonbg
Copy link
Member

For the v2/v3 conversion does this just affect output areas where \r could appear or also input areas?

For v3 notebooks before this PR, they will work fine, they just get the additional new line at the end of each line of text?

Not sure it is worth the effort to update all the notebooks, as the changes will be made gradually as we re-run those notebooks. But there is no harm in doing it if you want to.

@minrk
Copy link
Member Author

minrk commented Jun 7, 2012

It will only have a visible effect on manual downgrade from v3 to v2, and loaded into IPython 0.12, where everything will be perfectly functional, but all newlines will be duplicated.

After this change, multiline entries in ipynb files with the multiline cell containing 'line 1\rline 2\n' will go from:

    lines = [
        'line 1',
        'line 2',
    ]

to

    lines = [
        'line 1\r',
        'line 2\n',
    ]

@ellisonbg
Copy link
Member

OK I would probably just merge as is unless you really want to go through and update all the notebooks. But I don't think it is needed.

@fperez
Copy link
Member

fperez commented Jun 7, 2012

OK with me too, reviewed in-person.

Avoids discarding of information, e.g. `foo\rbar` should not be reconstructed as `foo\nbar`.

Implemented in safe manner, where notebooks written by old scheme will load the same as before, and be updated on next save.
minrk added a commit that referenced this pull request Jun 7, 2012
Keep line-endings in ipynb

Avoids discarding of information, e.g. foo\rbar should not be reconstructed as foo\nbar.

Implemented in safe manner, where notebooks written by old scheme will load the same as before, and be updated on next save.
@minrk minrk merged commit 0956514 into ipython:master Jun 7, 2012
@minrk minrk deleted the splitlines branch March 31, 2014 23:36
mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014
Keep line-endings in ipynb

Avoids discarding of information, e.g. foo\rbar should not be reconstructed as foo\nbar.

Implemented in safe manner, where notebooks written by old scheme will load the same as before, and be updated on next save.
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.

None yet

4 participants