...
> 10) This 6.a) strategy could eventually replace 2.a), but it does not
> have to, and we didn't went this way...
> So both Squeak 4.1 and Pharo 1.1 are not any worse than Squeak > always
> has been with this respect.

Except that now the conversion of Lf in Linux files to  Cr in Squeak no longer
occurs and this breaks things such as Menu labels.  Thus things that used
to work now don't.

> 11) Strategy 6.a) DOES NOT replace 2.b). If our down-chain
> applications are line-ending sensitive, then WE must care of producing
> the expected convention.

> Conclusions

> So my opinion is that 6.a) did not make our life worse.
> On the contrary, Squeak and Pharo are moving toward what I would call
> a better behaved I.T. world citizen.
> They now offers an API to handle line-endings transparently inside the image.
> This is at the price of not-so-much complexity, and no noticeable slow down.
> But now we have to learn new idioms (and I don't see nextLine as more
> complex than upTo: Character cr)...
> ... and apply it were due (like parsing menu specs) to obtain a
> homogeneous behaviour- goal 3)

> We still have to care of 2.b), and a bit less of 2.a) once 4.b) will
> be achieved.
> And maybe in the future, we will be able to get rid of 2.b) too when
> all applications will be line-ending-insensitive.
> In  the meantime, nothing prevents us to improve 2.a) and 2.b) to
> avoid LF leaking in or CR leaking out the image.
> But untill 2) strategy is perfect, then we just act as one of the bad
> world citizen perpetuating line-ending problems.
> IMO reaching goal 3) is easier than reaching goal 2).

> That's only my personal opinion, but it's based on pragmatic years of
> using bad line-ending behaved apps and trying to program a bit better
> ones.

> There are alternate possible strategies, like in CUIS: display a boxed
> [LF] explicitely in text editors so as to provide visual control to
> programmers...

> Not sure I sold my POV. It's quite opposite to your proposition.
> You don't have to adhere, but at least you have some rationale.

I consider getting  2a) and 2b) both quite important to work and
much more important than  6).  I suggest getting  2) to work first
and then worry about 6).

Also, beware with 6) that you don't want to fileIn a file from Linux
(or other operating system) and then fileOut the same file
only to find that a diff or cmp of the original and new versions of
the file reports
that they are different.  Similarly you don't want to fileOut a
method/Class/etc.
and then file it in again only to find that any diff like utility now
reports that the
original and new version are different because the  Cr-Lf  representation
of line separators has changed.
Of course, If you do 6) properly, it will make this problem less
likely rather than
more.

Beware too that any files, not necessarily .st files or Squeak files
that use both
Cr and Lf with distinct meanings will expect both to be loaded or
filed out without
any conversion of either character.

> Cheers

> Nicolas

How can I be cheerful when after 6 years of using Squeak I am still running
into these problem!  :-(  :-)

Regards,

Ralph Boland