[…] I prefer the more detailed syntax highlighting in VW.
Check the styler look for <style> in Pharo because you can create your own.
I don’t see this in Settings. I see “Syntax Highlighting…”
We need to do one for the dark theme.
There are a lot of variations.
I forgot all the differences, but recall more levels of parentheses can be
colored uniquely in VW and so can block-argument variables. That would be a
first small project: make Pharo syntax highlight at least as good as VW’s. I
need to do the same for formatting, which I've not checked out very thoroughly
yet.
For formatting check the BIformatter.
I cannot find class BIFormatter in the 7.0.3 image. What must I load?
We are working on
- adding tests (we have about 150 tests ready to get integrated
- working on a new tool to see and understand the settings
- we want to make sure that we can pretty print the complete system
so we will come probably with an extended pretty printer.
Sounds good.
The other thing that has been causing problems and about which I've written
some examples in Fogbugz (which no one is using anymore for Paro—and I didn’t
know, lol) is that Pharo labels are truncated if you switch to a monospace
font. I can't see what I'm doing some of the time because the labels are
chopped, and there is no automatic formatting of the fields to accommodate the
new font, which is not even very big--just normal-sized monospace. I suppose
Spec takes care of this problem systematically and that this is why nothing
else has been done to fix the problem.
Yes this is super annoying. Can you check with Spec 20 and this should be
fixed.
I’m not sure what Spec 20 is. Are you referring to this document in progress:
https://travis-ci.com/SquareBracketAssociates/BuildingApplicationWithSpec2
?
Now the font logic is one of the few parts that we did not revisit yet but it
is not way it should.
Also may users hardcode standardFonts….( the ugly singleton strike back).
Are you aware of "extension methods" ? Where a method you add to a built-in
Pharo class (Collection for example) is saved/loaded with your package.
Then you only need to manage your package not Pharo built-in packages as well.
Yes, I'm trying to get an Iceberg-on-Git groove going so that I can make my own
packages for extensions/overrides.
yes us know we can also do some screen sharing with you to get you up to speed.
[..]
Cloning the Pharo Track repo from the command line is done like this...
$ git clone <mailto:[email protected]:exercism/pharo-smalltalk.git>
[email protected]:exercism/pharo-smalltalk.git
Sure, but we can do this in Iceberg—and it works. So why use the command line?
which creates a folder with the same name as the repo (i.e. "pharo-smalltalk")
As a git GUI, Iceberg does the same. Indeed, Iceberg uses libgit2 to do this,
so the behaviour is standard git.
I was commenting on the ergonomics, and yes this is very much a Git thing.
Git is bad :) but this is the way to go.
The API sucks.
Yes, it has terminology problems too.
Shaping
