On Tue, May 2, 2017 at 5:23 PM, Nicolas Cellier <nicolas.cellier.aka.nice@ gmail.com> wrote:
2017-05-01 16:44 GMT+02:00 Ben Coman btc@openinworld.com:
On Fri, Apr 28, 2017 at 1:47 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
Ben,
On Apr 27, 2017, at 7:06 PM, Ben Coman btc@openinworld.com wrote:
On Fri, Apr 28, 2017 at 6:16 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Thu, Apr 27, 2017 at 2:38 PM, Nicolas Cellier < nicolas.cellier.aka.nice@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...)
Reading around this, it depends
If building in a Cygwin environment, then I guess that should have `tr`. But that doesn't help for building natively with MSVC.
Git For Windows (reasonably popular??) includes a bash shell + cygwin, so that should have `tr`. * https://git-for-windows.github.io/
GitHub for Windows includes PoshGit, based on Powershell * https://desktop.github.com/ and apparently you `tr` can be emulated in Powershell like this... * http://five.agency/powershell-tips-for-bash-users/
But maintaining separate scripts and determining which to install for users of random git software could get awkward. see "Why won't git hooks work on Windows" here... * https://tygertec.com/git-hooks-practical-uses-windows/
So perhaps the conversion to LFs remains a practical path forward. :shrugs:
Alternatively, although I don't quite grok these files... * https://github.com/git/git/blob/master/userdiff.c * https://github.com/git/git/blob/master/t/t4034-diff-words.sh * https://github.com/git/git/blob/master/t/t4018-diff-funcname.sh perhaps Smalltalk could be added to them, to presumably provide a "built in" gitattributes pattern... * https://git-scm.com/docs/gitattributes
cheers -ben
P.S. [off-topic] btw, Babun caught my eye as an interesting option. First I;ve heard of it... Hipsterising Windows: cygwin vs babun vs git bash vs powershell – the Onion scale https://macyves.wordpress.com/2014/09/18/hipsterising-windows-cygwin-vs-babu...
Babun - a windows shell you will love https://github.com/babun/babun