^M disappears upon forking

[rgbkrk]

^M disappears upon forking

[natw]

Huh, weird. Thanks, I'll look into that.

[natw]

I "fixed" this here: 444d041. I'm not sure why my first instinct was to use a literal ^M, but \n seems to work fine.

I'll send them a bug report about the forking issue, though. Data integrity is kind of a thing.

[rgbkrk]

I'm not sure why my first instinct was to use a literal ^M, but \n seems to work fine.

That's ok. Not being a master of vim scripting, I wasn't sure how to fix it but the forking issue led right to why it wouldn't display.

Data integrity is kind of a thing.

Looking forward to the bug report for the

[natw]

I can't reproduce this. What editor are you using? Cause looking at rgbkrk@d73bd59, it looks like you switched out the carriage return for the newline in your first commit.

[rgbkrk]

Oddly enough, I was just using the GitHub UI (chrome on Ubuntu Linux) to edit the file directly. When I was about to commit, I saw that a newline appeared. Oh. So perhaps Chrome is converting it... 😦 That would make sense.

Originally the steps to re-produce were:

• Click the keyboard_ cat.vim file in GitHub
• Click Edit
• Make a minimal commit
• Extra newline inserted.

The weird thing though is that when I was reproducing this (before you fixed it), it wouldn't let me make an "empty" commit. That is, I had not changed anything yet the commit button was greyed out.

[rgbkrk]

Try editing https://github.com/rgbkrk/ctrl-m/blob/master/trial.vim as a demo. GitHub will fork it for you.

[natw]

Yeah, it looks like it's the web editor that's interpreting a carriage return as a newline

Here's the edit I made: natw/ctrl-m@97c910a

Given that, I can't really get too riled up about this one.

[rgbkrk]

Given that, I can't really get too riled up about this one.

Yeah.

Of course, file view is borken as well.

[rgbkrk]

Closed this as it was a GitHub editor issue and @natw fixed it in 444d041.