On 2021-04-03, at 12:55 PM, Vanessa Freudenberg vanessa@codefrau.net wrote:

IMHO (speaking as a typo nerd) this is due to our default code font not having distinct enough letter shapes. I very much like our use of a proportional font, but maybe it's time to switch to a different one?

I din't think it's anything to do with proprtional fonts per se, but we could certainly do with some better font choices. And indeed a better manner of choosing them & setting them. The FontChooserTool is decent but the whole world-menu->appearance...->system fonts... thing is awful.

This a more than a bit amusing though since I'm in the middle watching Juan's excellent talk on Cuis & vector graphics - https://vimeo.com/532636234

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SVE: Skip on Vernal Equinox

On Sat, Apr 3, 2021 at 4:47 PM tim Rowledge tim@rowledge.org wrote:

...

On 2021-04-03, at 12:55 PM, Vanessa Freudenberg vanessa@codefrau.net

wrote:

...

IMHO (speaking as a typo nerd) this is due to our default code font not

having distinct enough letter shapes. I very much like our use of a proportional font, but maybe it's time to switch to a different one?

I din't think it's anything to do with proprtional fonts per se,

Only insofar as that I do not know a single proportional font that has been optimized for coding, as opposed to dozens of monospaced fonts (there is Input Sans, granted, but that looks very much monospaced with only a few adjustments).

I bet choosing the right glyph variants in some proportional font would help.

Tobi suggested Fira Sans, and while I like Spiekermann fonts in general and Fira Sans in particular, the rendering of e.g. ":=" is atrocious, because that combination just does not happen in "normal" text.

- Vanessa -

On 2021-04-04, at 2:53 PM, Benoit St-Jean via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:

A few suggestions here...

https://www.creativebloq.com/features/the-best-monospace-fonts-for-coding

I deeply dislike monospaced fonts for Smalltalk. Again, far too C. We're not programming mere machines here folks, we're having a conversation with objects.

How about https://fonts.google.com/specimen/Knewave ? :-) Teko is quite nice and clear. Or go really retro with 'Press Start 2P'.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One bit short of a word.

On 05/04/2021 07:32, Tobias Pape wrote:

I've been using Source Sans Pro (not Source Code, the mono variant) and Fira Sans for quite a while in different editors as proportional, sans-serif code fonts. The work very well.

I've come to like serif fonts for high dpi displays. Unfortunately, the one I want most is quite expensive (the serif version of Fira).

If we had ligatures, I think proper := is doable in any of these, and if we want to go all in, we can change these open source fonts to auto-mazing-ly replace them by left-arrow; and that visually only.

That would be amazing.

On 04/04/2021 23:06, tim Rowledge wrote:

I really wish there was a propelr left-arrow-assign for use to use. I hate ':='; it's so.... C

I thought it was taken from Pascal.

Douglas Brebner wrote on Mon, 5 Apr 2021 08:42:31 +0100

On 04/04/2021 23:06, tim Rowledge wrote:

...

I really wish there was a propelr left-arrow-assign for use to use. I hate ':='; it's so.... C

I thought it was taken from Pascal.

Digitalk introduced ":=" to Smalltalk in its Methods implementation for the IBM PC even though that machine did have a left arrow characeter (but with a very different encoding than 1963 ASCII used by Xerox). Given that the first part of the manual showed code fragments in Methods and Pascal side by side, it is clear that the choice was indeed made to make Pascal programmers (the most numerous in the early 1980s) feel at home.

See chapter 2 of

http://www.wirfs-brock.com/allen/files/digitalk/methods-language-guide.pdf

Note that not all PDF readers can handle this file.

-- Jecel

On 9. Apr 2021, at 20:27, Tom Beckmann tomjonabc@gmail.com wrote:

Fira Sans, 11

note that Fira Sans also has a slashed-Zero variant, which could come in handy…

(still my favourite…) -t

Hi

On 10. Apr 2021, at 05:32, Vanessa Freudenberg vanessa@codefrau.net wrote:

Thanks Tom, those look great! Kinda hard to pick a favorite really.

Tobias: how hard is it to pick a glyph variant when importing the font?

At the moment, impossible -.- But if we pre-render, as with the bitmap-dejavu, we have all control…

best regards -tobias

—Vanessa—

On Fri, Apr 9, 2021 at 11:35 AM Tobias Pape Das.Linux@gmx.de wrote:

...

On 9. Apr 2021, at 20:27, Tom Beckmann tomjonabc@gmail.com wrote:

Fira Sans, 11

note that Fira Sans also has a slashed-Zero variant, which could come in handy…

(still my favourite…) -t <Bildschirmfoto 2021-04-09 um 20.33.51.PNG>

Since we're on the subject of how our code looks: I would 💜 love 💜 if we had elastic tabstops by default in our code editors. This would eliminate (IMHO) the biggest counter-argument to using proportional fonts.

Vanessa

On Sat, Apr 3, 2021 at 12:55 PM Vanessa Freudenberg vanessa@codefrau.net wrote:

I just fixed a typo that went unnoticed for ~9 years (see KernelTests-codefrau.395). Even when Levente revised the code in 2015, he did not spot it:

[image: image.png]

IMHO (speaking as a typo nerd) this is due to our default code font not having distinct enough letter shapes. I very much like our use of a proportional font, but maybe it's time to switch to a different one?

• Vanessa -

On Sat, Apr 3, 2021 at 12:06 PM commits@source.squeak.org wrote:

...

Vanessa Freudenberg uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-codefrau.395.mcz

==================== Summary ====================

Name: KernelTests-codefrau.395 Author: codefrau Time: 3 April 2021, 12:06:03.17026 pm UUID: 062e8b73-a62e-46ce-af80-0dbb34c2f8dc Ancestors: KernelTests-mt.394

Fix typo in CompiledMethodComparisonTest.

=============== Diff against KernelTests-mt.394 ===============

Item was changed: ----- Method: CompiledMethodComparisonTest>>testHash (in category 'tests') ----- testHash <timeout: 120>

    | ai |
    ai := CompiledMethod allInstances.
    "We assume here that if two CompiledMethods are equal then they

have the same size and header." (ai groupBy: [ :method | { method size. method header } ]) values replace: [ :each | each asArray ]; do: [ :methods | 1 to: methods size do: [ :i | i to: methods size do: [ :j | (methods at: i) = (methods at: j) ifTrue: [

•                                           self assert: (methods at:
  

i) hash equals: (methods at: j) hash ] ] ] ]

•                                           self assert: (methods at:
  

i) hash equals: (methods at: i) hash ] ] ] ] displayingProgress: 'Testing hashes'. self assert: (ai collect: [ :cm | cm hash ] as: Set) size * 2 >= ai asSet size!

I would 💜 love 💜 if we had elastic tabstops by default in our code editors.

-1 for making this default behavior. :-) I think this is a matter of taste, but personally, I am not a friend of code that is not strictly left-justified, it just feels like wasted space to me. Please let's make it an optional preference.

Best, Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Tobias Pape Das.Linux@gmx.de Gesendet: Montag, 5. April 2021 22:39:10 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Elastic Tabstops (was Re: Need better default code font)

On 5. Apr 2021, at 22:37, Vanessa Freudenberg vanessa@codefrau.net wrote:

Since we're on the subject of how our code looks: I would 💜 love 💜 if we had elastic tabstops by default in our code editors. This would eliminate (IMHO) the biggest counter-argument to using proportional fonts.

+100 -t

Vanessa

On Sat, Apr 3, 2021 at 12:55 PM Vanessa Freudenberg vanessa@codefrau.net wrote: I just fixed a typo that went unnoticed for ~9 years (see KernelTests-codefrau.395). Even when Levente revised the code in 2015, he did not spot it:

<image.png>

IMHO (speaking as a typo nerd) this is due to our default code font not having distinct enough letter shapes. I very much like our use of a proportional font, but maybe it's time to switch to a different one?

• Vanessa -

On Sat, Apr 3, 2021 at 12:06 PM commits@source.squeak.org wrote: Vanessa Freudenberg uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-codefrau.395.mcz

==================== Summary ====================

Name: KernelTests-codefrau.395 Author: codefrau Time: 3 April 2021, 12:06:03.17026 pm UUID: 062e8b73-a62e-46ce-af80-0dbb34c2f8dc Ancestors: KernelTests-mt.394

Fix typo in CompiledMethodComparisonTest.

=============== Diff against KernelTests-mt.394 ===============

Item was changed: ----- Method: CompiledMethodComparisonTest>>testHash (in category 'tests') ----- testHash <timeout: 120>

    | ai |
    ai := CompiledMethod allInstances.
    "We assume here that if two CompiledMethods are equal then they have the same size and header."
    (ai groupBy: [ :method | { method size. method header } ]) values
            replace: [ :each | each asArray ];
            do: [ :methods |
                    1 to: methods size do: [ :i |
                            i to: methods size do: [ :j |
                                    (methods at: i) = (methods at: j) ifTrue: [

•                                           self assert: (methods at: i) hash equals: (methods at: j) hash ] ] ] ]
  

•                                           self assert: (methods at: i) hash equals: (methods at: i) hash ] ] ] ]
            displayingProgress: 'Testing hashes'.
    self assert: (ai collect: [ :cm | cm hash ] as: Set) size * 2 >= ai asSet size!
  
  
  
  

The only other example I was thinking of would be multi-line comments, but I dislike them anyway. :-)

Yes, speaking generally, subjective coding style preferences are a problem when writing or maintaining code in a community. I am still convinced that it would be the best solution to remove specific styling information from the Trunk code base and apply it on everyone's end only according to their personal preferences. With prettyDiff, which is already fairly well supported, and a good pretty-printer, this should be a feasible endeavor. PoppyPrint looks very promising to me in this regard.

Best,

Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Jakob Reschke jakres+squeak@gmail.com Gesendet: Mittwoch, 7. April 2021 18:04:32 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Elastic Tabstops (was Re: Need better default code font)

Hi,

The problem is, if it were a preference, for which setting will you write the Squeak Trunk code? A per-package setting dictated by the package maintainer sounds more practical to me, though it tends towards overengineering already.

The idea of elastic tabstops sounds good to me, but I have no practical experience with it. For the left-side-only indentation, I guess it will only make a difference if somebody wants a block with hanging indent like this:

| sum count | sum := anInteger. count := 0. aCollection do: [:each | sum := sum + each. count := count + 1]. "The first occurrences of sum and count are supposed to be left-aligned on the two lines above."

The example applies analogously if you want to start the remaining lines of the block at or just right of the [ of its first line and put the sum-mation on its own line.

Do you see other practical differences for our coding habits, everyone?

Kind regards, Jakob

Am Mi., 7. Apr. 2021 um 17:31 Uhr schrieb Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de>:

I would 💜 love 💜 if we had elastic tabstops by default in our code editors.

-1 for making this default behavior. :-) I think this is a matter of taste, but personally, I am not a friend of code that is not strictly left-justified, it just feels like wasted space to me. Please let's make it an optional preference.

Best, Christoph

________________________________ Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.demailto:Das.Linux@gmx.de> Gesendet: Montag, 5. April 2021 22:39:10 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Elastic Tabstops (was Re: Need better default code font)

On 5. Apr 2021, at 22:37, Vanessa Freudenberg <vanessa@codefrau.netmailto:vanessa@codefrau.net> wrote:

Since we're on the subject of how our code looks: I would 💜 love 💜 if we had elastic tabstops by default in our code editors. This would eliminate (IMHO) the biggest counter-argument to using proportional fonts.

+100 -t

Vanessa

On Sat, Apr 3, 2021 at 12:55 PM Vanessa Freudenberg <vanessa@codefrau.netmailto:vanessa@codefrau.net> wrote: I just fixed a typo that went unnoticed for ~9 years (see KernelTests-codefrau.395). Even when Levente revised the code in 2015, he did not spot it:

<image.png>

IMHO (speaking as a typo nerd) this is due to our default code font not having distinct enough letter shapes. I very much like our use of a proportional font, but maybe it's time to switch to a different one?

• Vanessa -

On Sat, Apr 3, 2021 at 12:06 PM <commits@source.squeak.orgmailto:commits@source.squeak.org> wrote: Vanessa Freudenberg uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-codefrau.395.mcz

==================== Summary ====================

Name: KernelTests-codefrau.395 Author: codefrau Time: 3 April 2021, 12:06:03.17026 pm UUID: 062e8b73-a62e-46ce-af80-0dbb34c2f8dc Ancestors: KernelTests-mt.394

Fix typo in CompiledMethodComparisonTest.

=============== Diff against KernelTests-mt.394 ===============

Item was changed: ----- Method: CompiledMethodComparisonTest>>testHash (in category 'tests') ----- testHash <timeout: 120>

    | ai |
    ai := CompiledMethod allInstances.
    "We assume here that if two CompiledMethods are equal then they have the same size and header."
    (ai groupBy: [ :method | { method size. method header } ]) values
            replace: [ :each | each asArray ];
            do: [ :methods |
                    1 to: methods size do: [ :i |
                            i to: methods size do: [ :j |
                                    (methods at: i) = (methods at: j) ifTrue: [

•                                           self assert: (methods at: i) hash equals: (methods at: j) hash ] ] ] ]
  

•                                           self assert: (methods at: i) hash equals: (methods at: i) hash ] ] ] ]
            displayingProgress: 'Testing hashes'.
    self assert: (ai collect: [ :cm | cm hash ] as: Set) size * 2 >= ai asSet size!
  
  
  
  

Alright, if it only affects rendering, then it should not be a big deal to make a preference for it. :-)

Tabbed comments are similar to traditional type-setting’s margin notes, that can be used to write table-like data, etc.

That's indeed an interesting use case for that I would like elastic tabstops, too! And here is another one: PasteUpMorph >> #defaultDesktopCommandKeyTriplets ... I would only dislike to indent blocks in this style. :-)

My point being that Smalltalk source code is not plain text. Never has been. It shouldn’t be treated as such. IMHO.

Well, my perspective on this question is that Smalltalk is literally small talk without all this nasty and complicated syntactic stuff you are used to from C-like languages and many others. So it's still not exactly plain text, but at least very near to it. You can just read (good) Smalltalk code like a book (and I have to say that I *love* this book :D). That's why in my personal opinion, Smalltalk code does not deserve a separate font compared to comments. :-)

Best, Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Vanessa Freudenberg vanessa@codefrau.net Gesendet: Mittwoch, 7. April 2021 18:22:16 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Elastic Tabstops (was Re: Need better default code font)

Guess you misunderstood - this does not affect indentation at all, it only affects the rendering of tabs following non-space characters in a line. And indeed there could be a preference to render those tabs as a space instead, however, that would probably lead to those text blocks being messed up accidentally.

The Smalltalk environment was meant to provide rich text rendering. We had text that could flow around objects at some point, that could flow along a curve, that could embed bitmaps and even arbitrary morphs. For some reason we went back to more or less plain text at least for code. I partly blame Monticello which did not preserve the rich formatting that the style chunks in the fileout format supported. I do find that unfortunate, however, and would love to get some richness back.

Tabbed comments are similar to traditional type-setting’s margin notes, that can be used to write table-like data, etc. You don’t have to use them, but I’m convinced it would make our codebase look a lot better.

Similarly, there’s no need for double quotes around comments. Comments should simply use a different font. Not coincidentally, that is exactly how commented code used to be printed in books. We only need the quotes for typing, and maybe for exporting, but otherwise I wouldn’t mind to never see them again.

My point being that Smalltalk source code is not plain text. Never has been. It shouldn’t be treated as such. IMHO.

Vanessa

On Wed, Apr 7, 2021 at 08:31 Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.demailto:Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:

I would 💜 love 💜 if we had elastic tabstops by default in our code editors.

-1 for making this default behavior. :-) I think this is a matter of taste, but personally, I am not a friend of code that is not strictly left-justified, it just feels like wasted space to me. Please let's make it an optional preference.

Best, Christoph

________________________________ Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.orgmailto:squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux@gmx.demailto:Das.Linux@gmx.de> Gesendet: Montag, 5. April 2021 22:39:10 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] Elastic Tabstops (was Re: Need better default code font)

On 5. Apr 2021, at 22:37, Vanessa Freudenberg <vanessa@codefrau.netmailto:vanessa@codefrau.net> wrote:

Since we're on the subject of how our code looks: I would 💜 love 💜 if we had elastic tabstops by default in our code editors. This would eliminate (IMHO) the biggest counter-argument to using proportional fonts.

+100 -t

Vanessa

On Sat, Apr 3, 2021 at 12:55 PM Vanessa Freudenberg <vanessa@codefrau.netmailto:vanessa@codefrau.net> wrote: I just fixed a typo that went unnoticed for ~9 years (see KernelTests-codefrau.395). Even when Levente revised the code in 2015, he did not spot it:

<image.png>

IMHO (speaking as a typo nerd) this is due to our default code font not having distinct enough letter shapes. I very much like our use of a proportional font, but maybe it's time to switch to a different one?

• Vanessa -

On Sat, Apr 3, 2021 at 12:06 PM <commits@source.squeak.orgmailto:commits@source.squeak.org> wrote: Vanessa Freudenberg uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-codefrau.395.mcz

==================== Summary ====================

Name: KernelTests-codefrau.395 Author: codefrau Time: 3 April 2021, 12:06:03.17026 pm UUID: 062e8b73-a62e-46ce-af80-0dbb34c2f8dc Ancestors: KernelTests-mt.394

Fix typo in CompiledMethodComparisonTest.

=============== Diff against KernelTests-mt.394 ===============

Item was changed: ----- Method: CompiledMethodComparisonTest>>testHash (in category 'tests') ----- testHash <timeout: 120>

    | ai |
    ai := CompiledMethod allInstances.
    "We assume here that if two CompiledMethods are equal then they have the same size and header."
    (ai groupBy: [ :method | { method size. method header } ]) values
            replace: [ :each | each asArray ];
            do: [ :methods |
                    1 to: methods size do: [ :i |
                            i to: methods size do: [ :j |
                                    (methods at: i) = (methods at: j) ifTrue: [

•                                           self assert: (methods at: i) hash equals: (methods at: j) hash ] ] ] ]
  

•                                           self assert: (methods at: i) hash equals: (methods at: i) hash ] ] ] ]
            displayingProgress: 'Testing hashes'.
    self assert: (ai collect: [ :cm | cm hash ] as: Set) size * 2 >= ai asSet size!
  
  
  
  

It seems to me that Shout obviates rather a lot of the concerns about formatting and elastic tabs and comments in different fonts etc.

Make Shout render the comments in a different font - it already does the colouring - and drop the " if you want. Keep the " as part of the raw markup. That leaves filed out code untouched. So far as I can see from a quick dig the Shout code works through the Themes stuff and can already cope with a font or emphasis being specified, so that just leaves the not-display of the ".

Make Shout handle the aligning of tabby-things. No need for any change in the raw code.

Way past time the pretty print was integrated with Shout too; better yet, time to allow some profiles of what is considered 'pretty'. I've been trying to use the Kent Beck blocky layout format recently; it's not terrible. I'm probably going a bit far with it right now but we learn as we go.

Also probably past time to drop the background shouting and redisplay thing; we're probably just wasting cycles here. Even a Pi2 didn't really have any problem...hmm, maybe for really big methods where some huge literal bitmap is defined?

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother!" said Pooh, as he stood up to his waist in a cow pat.

The reason appears to be that CompiledCode >> #hash takes the receiver class into consideration whereas CompiledCode >> #= doesn't.

So what behavior do we actually want?

If you remove the "+ self methodClass hash" from CompiledCode >> #hash, #testHash fails in the last statement instead because there are too many double hashes.

Should we respect the methodClass in CompiledCode >> #= as well?

I think this could actually make sense because the byte codes for inst var access are only meaningful in combination with the definition of the receiver class.

Opinions? :-)

Best,

Christoph

________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Vanessa Freudenberg vanessa@codefrau.net Gesendet: Montag, 5. April 2021 23:37:55 An: The general-purpose Squeak developers list Cc: packages@lists.squeakfoundation.org Betreff: Re: [squeak-dev] The Trunk: KernelTests-codefrau.395.mcz

Btw, I only fixed the test.

Which makes the test fail in trunk.

Eliot must have had a reason to create the test so Someone™️ should probably look at that. I probably don't have time for that soon.

- Vanessa -

On Sat, Apr 3, 2021 at 12:06 PM <commits@source.squeak.orgmailto:commits@source.squeak.org> wrote: Vanessa Freudenberg uploaded a new version of KernelTests to project The Trunk: http://source.squeak.org/trunk/KernelTests-codefrau.395.mcz

==================== Summary ====================

Name: KernelTests-codefrau.395 Author: codefrau Time: 3 April 2021, 12:06:03.17026 pm UUID: 062e8b73-a62e-46ce-af80-0dbb34c2f8dc Ancestors: KernelTests-mt.394

Fix typo in CompiledMethodComparisonTest.

=============== Diff against KernelTests-mt.394 ===============

Item was changed: ----- Method: CompiledMethodComparisonTest>>testHash (in category 'tests') ----- testHash <timeout: 120>

| ai | ai := CompiledMethod allInstances. "We assume here that if two CompiledMethods are equal then they have the same size and header." (ai groupBy: [ :method | { method size. method header } ]) values replace: [ :each | each asArray ]; do: [ :methods | 1 to: methods size do: [ :i | i to: methods size do: [ :j | (methods at: i) = (methods at: j) ifTrue: [ + self assert: (methods at: i) hash equals: (methods at: j) hash ] ] ] ] - self assert: (methods at: i) hash equals: (methods at: i) hash ] ] ] ] displayingProgress: 'Testing hashes'. self assert: (ai collect: [ :cm | cm hash ] as: Set) size * 2 >= ai asSet size!