[OpenSmalltalk/opensmalltalk-vm] 9fd4e3: Use LF instead of CR as image/*.st line ending

Hi Eliot,

it's not about my favourite editor, it's about the universally available one:

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351c4836734d1df3c880c288

The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF.
Could you explain?

2017-04-27 23:28 GMT+02:00 Eliot Miranda <[hidden email]>:

Please revert this.  It is easy to write a wrapper around your favourite editor to map returns.  These scripts should be in CR endings.

_,,,^..^,,,_ (phone)

> On Apr 27, 2017, at 12:32 PM, GitHub <[hidden email]> wrote:
>
>  Branch: refs/heads/Cog
>  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
>  Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0
>      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd4e371ae0895078fce13ea35c491daf0e448e0
>  Author: Nicolas Cellier <[hidden email]>
>  Date:   2017-04-27 (Thu, 27 Apr 2017)
>
>  Changed paths:
>    M .gitattributes
>    M image/BuildSpurReader64Image.st
>    M image/BuildSpurTrunk64Image.st
>    M image/BuildSqueakSpurTrunkVMMakerImage.st
>    M image/CompiledMethod-usesAlternateBytecodeSet.st
>    M image/FT2Constants.st
>    M image/LoadReader.st
>    M image/LoadSistaSupport.st
>    M image/Object-performwithwithwithwithwith.st
>    M image/RunATestClass.st
>    M image/StartReader.st
>    M image/UpdateSqueakTrunkImage.st
>
>  Log Message:
>  -----------
>  Use LF instead of CR as image/*.st line ending
>
> This is to be able to review/blame/ etc... from GitHub web interface (1 liner with 500+ columns is not tool friendly)
>
>
>  Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51
>      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c4881946c2bb8b7da7b191489dbf7ae180b05f51
>  Author: Nicolas Cellier <[hidden email]>
>  Date:   2017-04-27 (Thu, 27 Apr 2017)
>
>  Changed paths:
>    M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h
>    M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
>
>  Log Message:
>  -----------
>  Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog
>
>
> Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bfe983b7a720...c4881946c2bb

 

Hi Eliot,

it's not about my favourite editor, it's about the universally available one:

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351c4836734d1df3c880c288

The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF.
Could you explain?

2017-04-27 23:28 GMT+02:00 Eliot Miranda <[hidden email]>:

Please revert this.  It is easy to write a wrapper around your favourite editor to map returns.  These scripts should be in CR endings.

_,,,^..^,,,_ (phone)

> On Apr 27, 2017, at 12:32 PM, GitHub <[hidden email]> wrote:
>
>  Branch: refs/heads/Cog
>  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
>  Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0
>      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd4e371ae0895078fce13ea35c491daf0e448e0
>  Author: Nicolas Cellier <[hidden email]>
>  Date:   2017-04-27 (Thu, 27 Apr 2017)
>
>  Changed paths:
>    M .gitattributes
>    M image/BuildSpurReader64Image.st
>    M image/BuildSpurTrunk64Image.st
>    M image/BuildSqueakSpurTrunkVMMakerImage.st
>    M image/CompiledMethod-usesAlternateBytecodeSet.st
>    M image/FT2Constants.st
>    M image/LoadReader.st
>    M image/LoadSistaSupport.st
>    M image/Object-performwithwithwithwithwith.st
>    M image/RunATestClass.st
>    M image/StartReader.st
>    M image/UpdateSqueakTrunkImage.st
>
>  Log Message:
>  -----------
>  Use LF instead of CR as image/*.st line ending
>
> This is to be able to review/blame/ etc... from GitHub web interface (1 liner with 500+ columns is not tool friendly)
>
>
>  Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51
>      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c4881946c2bb8b7da7b191489dbf7ae180b05f51
>  Author: Nicolas Cellier <[hidden email]>
>  Date:   2017-04-27 (Thu, 27 Apr 2017)
>
>  Changed paths:
>    M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h
>    M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
>
>  Log Message:
>  -----------
>  Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog
>
>
> Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bfe983b7a720...c4881946c2bb

 

On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier <[hidden email]> wrote:

 

Hi Eliot,

it's not about my favourite editor, it's about the universally available one:

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351c4836734d1df3c880c288

The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF.
Could you explain?

It's ok.  I give up.  This is another example of the tail wagging the dog, which gets on my nerves.  But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.

 

2017-04-27 23:28 GMT+02:00 Eliot Miranda <[hidden email]>:

Please revert this.  It is easy to write a wrapper around your favourite editor to map returns.  These scripts should be in CR endings.

_,,,^..^,,,_ (phone)

> On Apr 27, 2017, at 12:32 PM, GitHub <[hidden email]> wrote:
>
>  Branch: refs/heads/Cog
>  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
>  Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0
>      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd4e371ae0895078fce13ea35c491daf0e448e0
>  Author: Nicolas Cellier <[hidden email]>
>  Date:   2017-04-27 (Thu, 27 Apr 2017)
>
>  Changed paths:
>    M .gitattributes
>    M image/BuildSpurReader64Image.st
>    M image/BuildSpurTrunk64Image.st
>    M image/BuildSqueakSpurTrunkVMMakerImage.st
>    M image/CompiledMethod-usesAlternateBytecodeSet.st
>    M image/FT2Constants.st
>    M image/LoadReader.st
>    M image/LoadSistaSupport.st
>    M image/Object-performwithwithwithwithwith.st
>    M image/RunATestClass.st
>    M image/StartReader.st
>    M image/UpdateSqueakTrunkImage.st
>
>  Log Message:
>  -----------
>  Use LF instead of CR as image/*.st line ending
>
> This is to be able to review/blame/ etc... from GitHub web interface (1 liner with 500+ columns is not tool friendly)
>
>
>  Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51
>      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c4881946c2bb8b7da7b191489dbf7ae180b05f51
>  Author: Nicolas Cellier <[hidden email]>
>  Date:   2017-04-27 (Thu, 27 Apr 2017)
>
>  Changed paths:
>    M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h
>    M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
>
>  Log Message:
>  -----------
>  Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog
>
>
> Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bfe983b7a720...c4881946c2bb

--

_,,,^..^,,,_

best, Eliot

> On 27-04-2017, at 7:06 PM, Ben Coman <[hidden email]> wrote:
>
> Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?

Err, yeah. It’s how Smalltalk works.

 

Ben,

On Apr 27, 2017, at 7:06 PM, Ben Coman <[hidden email]> wrote:

On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda <[hidden email]> wrote:

 

On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier <[hidden email]> wrote:

 

Hi Eliot,

it's not about my favourite editor, it's about the universally available one:

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351c4836734d1df3c880c288

The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF.
Could you explain?

It's ok.  I give up.  This is another example of the tail wagging the dog, which gets on my nerves.  But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.

Its not github!  When looking into Sophie's issue, opening those ST scripts were unreadable 

when opened in `vi` .  It was a pain that I had to break context to hunt for a GUI text app to read them

It's a three liner to wrap vi in a script that converts from CR to LF, invokes vi and then concerts back.  Is it really that problematic?

CR-only line endings are sooooooo last century, for machines like: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Oberon, the classic Mac OS up to version 9, MIT Lisp Machine and OS-9 [1].  These dogs died a long time ago ;)

Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?

[1] https://en.wikipedia.org/wiki/Newline

cheers -ben

 

2017-04-27 23:28 GMT+02:00 Eliot Miranda <[hidden email]>:

Please revert this.  It is easy to write a wrapper around your favourite editor to map returns.  These scripts should be in CR endings.

_,,,^..^,,,_ (phone)

> On Apr 27, 2017, at 12:32 PM, GitHub <[hidden email]> wrote:
>
>  Branch: refs/heads/Cog
>  Home:   https://github.com/OpenSmalltalk/opensmalltalk-vm
>  Commit: 9fd4e371ae0895078fce13ea35c491daf0e448e0
>      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/9fd4e371ae0895078fce13ea35c491daf0e448e0
>  Author: Nicolas Cellier <[hidden email]>
>  Date:   2017-04-27 (Thu, 27 Apr 2017)
>
>  Changed paths:
>    M .gitattributes
>    M image/BuildSpurReader64Image.st
>    M image/BuildSpurTrunk64Image.st
>    M image/BuildSqueakSpurTrunkVMMakerImage.st
>    M image/CompiledMethod-usesAlternateBytecodeSet.st
>    M image/FT2Constants.st
>    M image/LoadReader.st
>    M image/LoadSistaSupport.st
>    M image/Object-performwithwithwithwithwith.st
>    M image/RunATestClass.st
>    M image/StartReader.st
>    M image/UpdateSqueakTrunkImage.st
>
>  Log Message:
>  -----------
>  Use LF instead of CR as image/*.st line ending
>
> This is to be able to review/blame/ etc... from GitHub web interface (1 liner with 500+ columns is not tool friendly)
>
>
>  Commit: c4881946c2bb8b7da7b191489dbf7ae180b05f51
>      https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c4881946c2bb8b7da7b191489dbf7ae180b05f51
>  Author: Nicolas Cellier <[hidden email]>
>  Date:   2017-04-27 (Thu, 27 Apr 2017)
>
>  Changed paths:
>    M platforms/Cross/plugins/CroquetPlugin/CroquetPlugin.h
>    M platforms/Cross/plugins/CroquetPlugin/TriBoxStub.c
>
>  Log Message:
>  -----------
>  Merge branch 'Cog' of https://github.com/OpenSmalltalk/opensmalltalk-vm into Cog
>
>
> Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/bfe983b7a720...c4881946c2bb

--

_,,,^..^,,,_

best, Eliot

 

Ben,

On Apr 27, 2017, at 7:06 PM, Ben Coman <[hidden email]> wrote:

On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda <[hidden email]> wrote:

 

On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier <[hidden email]> wrote:

 

Hi Eliot,

it's not about my favourite editor, it's about the universally available one:

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351c4836734d1df3c880c288

The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF.
Could you explain?

It's ok.  I give up.  This is another example of the tail wagging the dog, which gets on my nerves.  But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.

Its not github!  When looking into Sophie's issue, opening those ST scripts were unreadable 

when opened in `vi` .  It was a pain that I had to break context to hunt for a GUI text app to read them

CR-only line endings are sooooooo last century, for machines like: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Oberon, the classic Mac OS up to version 9, MIT Lisp Machine and OS-9 [1].  These dogs died a long time ago ;)

Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?

[1] https://en.wikipedia.org/wiki/Newline

Ben,

There's no need to have three ways to do the same thing, line ending. 

So Smalltalk has chosen one and stick to it. it was CR. 

Thus you will see a message #cr used everywhere in the code base (either sent to Character or to a WriteStream to write an end of line).

Also, carriage return is used thru a CR variable in TextConstants pool dictionary.

The wisdom was that connections to/from outside world (external streams like files/sockets...) should do the conversion in/out the Smalltalk space.

But this has been inequally applied, especially in Squeak/Pharo where the zoo of Stream is not so well engineered (it's a mess!).

Since the boundary was messy, I've taken the responsibility to introduce the complexity inside the code base by:

- changing display of LF and adding hacks to display a single end of line in case of CR-LF pair

- introduce nextLine et a few other methods to deal with the zoo of line endings

I'm still not completely sure that it was a good idea... Maybe 

If we want to change our conventions to be more fashioned, we must get rid of cr message in the code base and replace it with something like eol (end of line).

Cuis has changed the CR to LF inside the image.

 

On Fri, Apr 28, 2017 at 1:47 PM, Eliot Miranda <[hidden email]> wrote:

 

Ben,

On Apr 27, 2017, at 7:06 PM, Ben Coman <[hidden email]> wrote:

On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda <[hidden email]> wrote:

 

On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier <[hidden email]> wrote:

 

Hi Eliot,

it's not about my favourite editor, it's about the universally available one:

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351c4836734d1df3c880c288

The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF.
Could you explain?

It's ok.  I give up.  This is another example of the tail wagging the dog, which gets on my nerves.  But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.

Its not github!  When looking into Sophie's issue, opening those ST scripts were unreadable 

when opened in `vi` .  It was a pain that I had to break context to hunt for a GUI text app to read them

I'd advocate going to LF EOL, but if its really important, a bit of research dug up how git can work with CR-line-ending

Here is a recipe to demonstrate the effect. 

First restore one commit back from "Use LF instead of CR as image/*.st line ending"

$ git status    # && git stash  # if required  

$ git checkout 9fd4e371~1

HEAD detached at 11d990e

nothing to commit, working directory clean

$ git diff

no output, okay.

Make a change in directory opensmalltalk-vm/image/

$ vi StartReader.st

         insert a line "comment 1"

$ git diff  

@@ -1 +1 @@

-Transcript clear.^MSmalltalk snapshot: true andQuit: true.^M[[Processor activeProcess bindToThreadId: 2]^M     on: Error^M     do: [:ex|].^M StdioListener new run] forkAt: Processor activePriority + 1

+"comment 1"^MTranscript clear.^MSmalltalk snapshot: true andQuit: true.^M[[Processor activeProcess bindToThreadId: 2]^M        on: Error^M     do: [:ex|].^M StdioListener new run] forkAt: Processor activePriority + 1^M

yuck!

Add a git filter for ST files...

$ vi opensmalltalk-vm/.git/config

    append...

        [filter "crLineEnd"]

             clean = tr '\\r' '\\n'

             smudge = tr '\\n' '\\r'

$ vi opensmalltalk-vm/.gitattributes

    append...

        *.st filter=crLineEnd

Commit file so that EOLs are updated to LF internal to git.

In directory opensmalltalk-vm/image/ ...

$ git add StartReader.st

$ git commit -m "apply filter - test only, throw away"

Now make a second change...

$ vi StartReader.st

        insert line "comment 2"

$ git diff

@@ -1,4 +1,5 @@

 "comment 1"

+"comment 2"

 Transcript clear.

 Smalltalk snapshot: true andQuit: true.

 [[Processor activeProcess bindToThreadId: 2]

Better!  

I didn't test it on github, but IIUC it just uses `git diff`

 

It's a three liner to wrap vi in a script that converts from CR to LF, invokes vi and then concerts back.  Is it really that problematic?

Its not immediately obvious to me how to do that (maybe sed or tr to a temporary file that vi then edits?)

So "three lines" is not really a measure of the effort required to work out how to implement it, 
and test that doesn't conflict with normal 'vi' usage. All this breaks from the context of what I was doing.  

Anyhow Tobias's vimrc advice works. 

On Fri, Apr 28, 2017 at 8:03 PM, David T. Lewis <[hidden email]> wrote:

On Fri, Apr 28, 2017 at 09:39:28AM +0200, Tobias Pape wrote:
>
> (in .vimrc)
>
> set fileformats=unix,mac,dos

Tobias,

Thank you! I can't believe I have gone so many years without ever knowing
about this simple editor setting.

Dave

Also thx Tobias.  So many little corners of knowledge.

This works good for me.  Still not so good for the next newcomer that doesn't know this.   

CR-only line endings are sooooooo last century, for machines like: Commodore 8-bit machines, Acorn BBC, ZX Spectrum, TRS-80, Apple II family, Oberon, the classic Mac OS up to version 9, MIT Lisp Machine and OS-9 [1].  These dogs died a long time ago ;)

Is there something particularly Smalltalk related I'm not aware of that makes CR-only line endings preferable?

[1] https://en.wikipedia.org/wiki/Newline

On Fri, Apr 28, 2017 at 3:48 PM, Nicolas Cellier <[hidden email]> wrote:

Ben,

There's no need to have three ways to do the same thing, line ending. 

So Smalltalk has chosen one and stick to it. it was CR. 

Back when Smalltalk was created, I guess CR was the dominant platform line ending and so was the choice was "align with the dominant convention".  Now that the dominant convention has progressed, the question arises whether to follow to reduce friction with other systems.   The trouble of course being that there are two competing line endings LF & CRLF.

 

Thus you will see a message #cr used everywhere in the code base (either sent to Character or to a WriteStream to write an end of line).

Ahh. I never made that connection before. 

 

Also, carriage return is used thru a CR variable in TextConstants pool dictionary.

The wisdom was that connections to/from outside world (external streams like files/sockets...) should do the conversion in/out the Smalltalk space.

But this has been inequally applied, especially in Squeak/Pharo where the zoo of Stream is not so well engineered (it's a mess!).

Since the boundary was messy, I've taken the responsibility to introduce the complexity inside the code base by:

- changing display of LF and adding hacks to display a single end of line in case of CR-LF pair

- introduce nextLine et a few other methods to deal with the zoo of line endings

I'm still not completely sure that it was a good idea... Maybe 

If we want to change our conventions to be more fashioned, we must get rid of cr message in the code base and replace it with something like eol (end of line).

 

Cuis has changed the CR to LF inside the image.

I guess Cuis aligned closely with git since thats its main mechanism for its sources (??).

GNU Smalltalk uses LF (its aligned with Unix).

Dolphin uses CRLF (its aligned with Windows) 

Theoretically, a move to the Unicode Line Separator U+2038 might solve all problems, 
   http://unicode.org/standard/reports/tr13/tr13-5.html

but practically it doesn't (yet) seem supported by vim or emacs
And of course, there is this about Standards...   https://xkcd.com/927   .

cheers -ben

 

2017-05-01 16:44 GMT+02:00 Ben Coman <[hidden email]>:

 

Theoretically, a move to the Unicode Line Separator U+2038 might solve all problems, 
   http://unicode.org/standard/reports/tr13/tr13-5.html

but practically it doesn't (yet) seem supported by vim or emacs
And of course, there is this about Standards...   https://xkcd.com/927   .

Hmm, yet another line ending...
To me it sounds too much like what I call a "Trojan badger"...
(from the sketch of Monty Python Holly Grail where the knights of the round table forgot to climb into the Trojan rabbit, and after a blank, one suggest to build a wooden badger)

 

2017-05-01 16:44 GMT+02:00 Ben Coman <[hidden email]>:

 

On Fri, Apr 28, 2017 at 1:47 PM, Eliot Miranda <[hidden email]> wrote:

 

Ben,

On Apr 27, 2017, at 7:06 PM, Ben Coman <[hidden email]> wrote:

On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda <[hidden email]> wrote:

 

On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier <[hidden email]> wrote:

 

Hi Eliot,

it's not about my favourite editor, it's about the universally available one:

https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c9ef837f7b0914351c4836734d1df3c880c288

The LF are displayed correctly in Squeak/Pharo and we can use nextLine in replacement of upTo: Character cr, so I fail to see the problem of LF.
Could you explain?

It's ok.  I give up.  This is another example of the tail wagging the dog, which gets on my nerves.  But getting them to fix their interface is way more difficult than us accommodating their limitations so go ahead.

Its not github!  When looking into Sophie's issue, opening those ST scripts were unreadable 

when opened in `vi` .  It was a pain that I had to break context to hunt for a GUI text app to read them

I'd advocate going to LF EOL, but if its really important, a bit of research dug up how git can work with CR-line-ending

Here is a recipe to demonstrate the effect. 

First restore one commit back from "Use LF instead of CR as image/*.st line ending"

$ git status    # && git stash  # if required  

$ git checkout 9fd4e371~1

HEAD detached at 11d990e

nothing to commit, working directory clean

$ git diff

no output, okay.

Make a change in directory opensmalltalk-vm/image/

$ vi StartReader.st

         insert a line "comment 1"

$ git diff  

@@ -1 +1 @@

-Transcript clear.^MSmalltalk snapshot: true andQuit: true.^M[[Processor activeProcess bindToThreadId: 2]^M     on: Error^M     do: [:ex|].^M StdioListener new run] forkAt: Processor activePriority + 1

+"comment 1"^MTranscript clear.^MSmalltalk snapshot: true andQuit: true.^M[[Processor activeProcess bindToThreadId: 2]^M        on: Error^M     do: [:ex|].^M StdioListener new run] forkAt: Processor activePriority + 1^M

yuck!

Add a git filter for ST files...

$ vi opensmalltalk-vm/.git/config

    append...

        [filter "crLineEnd"]

             clean = tr '\\r' '\\n'

             smudge = tr '\\n' '\\r'

$ vi opensmalltalk-vm/.gitattributes

    append...

        *.st filter=crLineEnd

Commit file so that EOLs are updated to LF internal to git.

In directory opensmalltalk-vm/image/ ...

$ git add StartReader.st

$ git commit -m "apply filter - test only, throw away"

Now make a second change...

$ vi StartReader.st

        insert line "comment 2"

$ git diff

@@ -1,4 +1,5 @@

 "comment 1"

+"comment 2"

 Transcript clear.

 Smalltalk snapshot: true andQuit: true.

 [[Processor activeProcess bindToThreadId: 2]

Better!  

I didn't test it on github, but IIUC it just uses `git diff`

 

Thanks for the tip. Sounds like a viable way to not change our line end policy.

The only thing I wonder: is unixy tr available on every client? (think windows...)