[squeak-dev] Manual line breaks in code (was: The Trunk: Collections-ct.999.mcz

Marcel Taeumel marcel.taeumel at hpi.de
Fri Apr 8 08:43:57 UTC 2022


Hi Christoph --

> I'm not yet convinced. :-) In almost all situations, I do not see any other sense
> in manual line breaks in comments than working around the absence of a proper
> line-breaking mechanism. There is (or should not be) any need for this nowadays.

First we shape our tools. And then our tools shape us. :-)

One way is not better or worse then the other way, especially, if you notice that
people cannot agree on a common way but that more complex forces seem to
be at play.

Someone likes to resize windows; another one may not.
Someone likes to insert hard line breaks; another one may not.
Someone knows how to configure tools; another one may not.

We should learn to respect and accept each others preferences. To not annoy
one another more than necessary. :-D

Best,
Marcel
Am 01.04.2022 13:43:14 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi Marcel, Hi Lauren,

> I know that some of us tend to remove manual line breaks in such longer comments but we might want to stop doing that if it is easy the retain the original format.

I'm not yet convinced. :-) In almost all situations, I do not see any other sense in manual line breaks in comments than working around the absence of a proper line-breaking mechanism. There is (or should not be) any need for this nowadays. If we want to reduce noise on the mailing list, I would rather consider this a tooling problem.

> That said, it would be nice to have a feature in SmalltalkEditor or TextEditor that converts the soft line breaks of the current text selection into hard line breaks and vice versa.

My first impression of this proposal would be that it would complicate understanding what's actually in a text vs how the text is displayed ... too many abstractions ...

Anyway, thanks for the pointers to the preferences!

> How about email's format=flowed?

A problem with this could be that some systems do not preserve trailing spaces. For instance, they do not appear in the mailing list archive. :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]

On 2022-03-29T10:57:30-06:00, drurowin at gmail.com wrote:

> Hi Marcel, Christoph,
>
> On Tue, Mar 29, 2022, 01:58 Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
>
> > Hi Christoph --
> >
> > Thanks. Treat this as a piece of pre-formatted document. It is actually
> > like source code where authors sometimes want to pre-format the linebreaks
> > of a longer comment to not have to fiddle around with window resizing.
> >
> > I know that some of us tend to remove manual line breaks in such longer
> > comments but we might want to stop doing that if it is easy the retain the
> > original format.
> >
> > For longer comments without extra line breaks, the following preference
> > can help programmers that have troubles reading other author's source code:
> >
> > PluggableTextMorph softLineWrap: false.
> > PluggableTextMorph visualWrapBorder: true.
> > PluggableTextMorph softLineWrapAtVisualWrapBorder: true.
> > PluggableTextMorph visualWrapBorderLimit: 80.
> >
> > That said, it would be nice to have a feature in SmalltalkEditor or
> > TextEditor that converts the soft line breaks of the current text selection
> > into hard line breaks and vice versa.
> >
> > Then we can more easily preserve both styles of formatting longer
> > commentary. :-)
> >
> How about email's format=flowed? It uses a trailing space to indicate the
> next line can be merged and wrapped according to the viewer's preferences.
> We could visually mark that special end-of-line space in source mode so
> it's obvious, but then process it in pretty print and documentation.
>
> This line
> would be
> merged
> with the rest.
> But this would be
> forced to a new one.
> Select the text to see the trailing blanks.
>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220329/9948517e/attachment.html>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220408/1248bd60/attachment.html>


More information about the Squeak-dev mailing list