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 <[hidden email]> im Auftrag von Jakob Reschke <jakres+[hidden email]>
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 <[hidden email]>:
Carpe Squeak!
|
In reply to this post by Christoph Thiede
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 <[hidden email]> wrote:
|
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 <[hidden email]> im Auftrag von Vanessa Freudenberg <[hidden email]>
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 <[hidden email]> wrote:
Carpe Squeak!
|
Am Mi., 7. Apr. 2021 um 18:41 Uhr schrieb Thiede, Christoph <[hidden email]>:
Well, it depends. In my hanging indent example with elastic tabstops you would write less tab stops on the hanging lines and at least one additional tab stop on the first line of the block. Whereas without elastic tabstops you would push tab or space repeatedly until you are somewhat satisfied with the results for your particular font setting, to achieve the same looks. One source code will contain different characters (tabs) than the other. Some intelligent rendering that makes both codes look like indented in the same, properly aligned way might be nice. As a compromise between unformatted and pretty-printed browsing. With these additional ideas like not showing the quotes, there will be at least two meanings of "pretty print" in the future.
(It is certainly better than typedef char (*pointerToArrays)[6]; but Smalltalk, too, has its unnatural plain text/keyboard quirks/compromises like ~= or historical syntax artifacts like the colon in block arguments—if I remember that correctly from the evolution of Smalltalk article from last year. And there was already a remark about the looks of := with certain fonts.) Comments looking like sticky notes in PDFs would be fancy. And less portable, of course.
;-)
"This package is best browsed with Squeak 5.4, standard system browser, elastic tabstops and automatic rendering of ←, ↑ enabled, quotes disabled, and a display size of at least 1024x768. What do you mean, you are still using Internet Explorer?" Kidding aside, preferences and rendering fragmentation might, here too, be a problem for authors and readers. No objections
from me personally against improving the tools and rendering. |
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; [hidden email]; http://www.rowledge.org/tim "Bother!" said Pooh, as he stood up to his waist in a cow pat. |
In reply to this post by Jecel Assumpcao Jr
Hi everyone, I went ahead and loaded some of the fonts mentioned in this thread and gave them a spin in the image. Note that these are rendered with freetype, so if you use Balloon2D you may get different results. If you have other favorites or a preferred method to "benchmark" the looks, let me know. Input Sans, 10 Ubuntu Mono, 11 Roboto, 11 Fira Sans, 11 Source Sans Pro, 12 Best, Tom On Mon, Apr 5, 2021 at 10:37 PM Jecel Assumpcao Jr <[hidden email]> wrote: Douglas Brebner wrote on Mon, 5 Apr 2021 08:42:31 +0100 |
On 9. Apr 2021, at 20:27, Tom Beckmann <[hidden email]> wrote: note that Fira Sans also has a slashed-Zero variant, which could come in handy… (still my favourite…) -t |
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? —Vanessa— On Fri, Apr 9, 2021 at 11:35 AM Tobias Pape <[hidden email]> wrote:
|
Hi
> On 10. Apr 2021, at 05:32, Vanessa Freudenberg <[hidden email]> 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 <[hidden email]> wrote: > > >> On 9. Apr 2021, at 20:27, Tom Beckmann <[hidden email]> 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> > > |
On Sat, Apr 10, 2021 at 00:02 Tobias Pape <[hidden email]> wrote: Hi That’s what I thought Tom was doing, so that’s what I meant, yes, just for importing a new bitmapped default code font. Would it have to be font-specific (e.g. for “Fira Sans” pick variant 2 for the zero glyph) or is there a generic way to say “if this font has multiple glyphs for zero, prefer the slashed variant”). That’s where my knowledge of font tech does not go far enough. –Vanessa–
|
Free forum by Nabble | Edit this page |