Re: @ SCOS Message Format ?

Richard Heathfield <rjh@cpax.org.uk> wrote:

On 24/02/2025 21:36, Rich wrote:

Richard Heathfield <rjh@cpax.org.uk> wrote:

On 24/02/2025 18:08, Rich wrote:

Richard Heathfield <rjh@cpax.org.uk> wrote:

>
Given this input:
>
[long input snipped]

>

$md5sum charset.txt
d5c6d06587dbac07fed831293ff0580d  charset.txt
$ md5sum charset.scos2
87ea4967605a5ba4d69ff6cf0fb541f5  charset.scos2
>
Anyone get anything different?

>
Mouse copy/paste from Tin running inside a Urxvt terminal results in
identical md5's to yours above:
>
    $ md5sum *
    d5c6d06587dbac07fed831293ff0580d  charset.txt
    87ea4967605a5ba4d69ff6cf0fb541f5  charset.scos2

>
Thanks for that. So it is beginning to look like a fair lot of
noise over not very much.

 
I'd say if one is using a newsreader that /does/ perform such
"transformations" -- and one is unaware such is happening, that for
those "ones" it is more than noise.  In fact, with Tin, if one
surrounds words/strings with stars or forward slashes, Tin attempts to
highlight those, and IIRC it hides the stars/slashes, so depending on
just what character sequence is output, I might have had a different
md5 from mouse copy/paste.
 
I.e. the word bold below should end up bold in Tin but without stars:
 
*bold*

 
My newsreader correctly echoed the asterisk characters, and your
newsreader correctly sent the text without corrupting the text.
Here's the article source (between the +rows):
 
+++++++++++++++++++++++++++++++++++++++
I.e. the word bold below should end up bold in Tin but without stars:
 
*bold*
 
And the word italics below should be in italics (if my terminal
'did'
italics, that is):
 
/italics/

Tin removed the stars and slashes (for display), and made the slashes
be underlined in the terminal.  I suspect the stars should have been
bold, but a bold font face was not used for the display in any case.

Copy and paste from the terminal display resulted in no stars or
slashes around "bold" or "italics".  So for those specific cases, if
those patterns cropped up, Tin in a terminal would also corrupt the
"text".

However, both "saving" the article to a file, and "piping" the article
to less, resulted in the stars and slashes being present in both.  So
the issue is only with display in the terminal (at least with Tin).

So your reader works and so does mine, and it seems that neither
is a good example of a reader that corrupts data.

Mostly.  For the particular 'patterns' that Tin recognizes, it too
'corrupted'.  It simply appears that other newsreaders recognize many
more patterns, leading to more occurrences of "change" from what was
originally created.

Here is what Tin recognizes, and the 'highlight' it defaults to:

     60 Attr. of highlighting with *stars*                   : Bold                                                        
     61 Attr. of highlighting with _dash_                    : Underline
     62 Attr. of highlighting with /slash/                   : Half bright
     63 Attr. of highlighting with -stroke-                  : Reverse video

There is also a singe globlal setting to turn off all of the above, and
testing with it off, I get the stars and slashes without modification. 
So there is a way to avoid the issue, if it is causing trouble, with
Tin.

Yes, of course it's true that if you're using broken software you
might have trouble with corrupted data, but frankly if my accounts
software started turning 7s into 1s, I would achieve better results
by replacing my accounts software than I would by asking my
accountant to stop using 7s in his sums.

Agreed.  But it is also possible for the other newsreaders that there
is one or more of:

A save or pipe option that does not perform the visual character
translations.

A toggle to turn off the visual character translations.

However, in this case, possibly suggesting that folks go looking for
save/pipe/turn off options might be more fruitful than suggesting they
switch away from X to Y when they presumably have some preference for X
(or at least familarity with X).