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

Tue May 2 09:23:13 UTC 2017

2017-05-01 16:44 GMT+02:00 Ben Coman <btc at openinworld.com>:

>
>
>
> On Fri, Apr 28, 2017 at 1:47 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>>
>> Ben,
>>
>> On Apr 27, 2017, at 7:06 PM, Ben Coman <btc at openinworld.com> wrote:
>>
>> On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>>
>>>
>>> On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>
>>>>
>>>> Hi Eliot,
>>>> it's not about my favourite editor, it's about the universally
>>>> available one:
>>>>
>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57c
>>>> 9ef837f7b0914351c4836734d1df3c880c288
>>>>
>>>> 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...)

>
> 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 <lewis at mail.msen.com>
> 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 <nicolas.cellier.aka.
> nice at gmail.com> 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   .
>
>
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)

> cheers -ben
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170502/5d66c3e4/attachment-0001.html>