Hello Maurice,

On Thu, Nov 28 2024 10:36:22 -0600, you wrote ..

... þa þurfon swiþe lytles, þe maran ne willniaþ þonne genoges.

Originally yes but over the years have added to the list. However not
all are Anglo-Saxon although the majority are. They all have utf-8 characters since that was the main reason for the tagline list
although the Anglo-Saxon ones were to ensure "English only" text for
those anal moderators. ;-)

While I already responded to this, here is a test with nano and the "set fill 72" option set in .nanorc. With this setting, while replying, going to the first quote character in your unwrapped long line/paragraph and hitting CTRL-J wraps the entire sentence/paragraph at 72 characters quite nicely (much like the 'gq' does in vim).

However, as of right now the spaces at the end of the lines are included (to keep flowed text in tact), and in a quote this may not be wanted. Otherwise, if it wraps the quoted text nicely then we may be on to something here! :)

Regards,
Nick

... He who laughs last, thinks slowest.
--- SBBSecho 3.23-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)

Hey Nick!

here is a test with nano and the "set fill 72" option set in
.nanorc.

It looks great from this angle. From this perspective the result looks the same output as
fold -s -w 69 | sed 's/^/ > /'
produces. I may switch to that output very soon with or without mutt.

the spaces at the end of the lines are included (to keep flowed
text in tact), and in a quote this may not be wanted.

And then again maybe it is given it makes it far easier to reconstruct the original posted text, including lines, paragraphs, and the such. It looks to be a keeper.

if it wraps the quoted text nicely then we may be on to something
here!

It looks that way to me. I'll definetly get back to you on this once I get a chance to compare outputs between nano and a properly scripted (bash) fold/sed quotes. So far I like what I see in this post -> "@MSGID: 233.tuxpower@1:154/700 2bb4e7ca".

Life is good,
Maurice

-o o- o- -o
(\ /) /) (\
^^ ^^ ^^ ^^
... Eadig biþ se þe eaþmod leofaþ; cymeþ him seo ar of heofonum.
Blessed is he who lives humbly; mercy comes to him from heaven.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice,

On Wed, Dec 04 2024 13:30:05 -0600, you wrote ..

And then again maybe it is given it makes it far easier to reconstruct
the original posted text, including lines, paragraphs, and the such.
It looks to be a keeper.

Originally I didn't know what it would do, but if it makes it easier to reconstruct for others, then I don't need to make any further changes at this time! :)

It looks that way to me. I'll definetly get back to you on this once
I get a chance to compare outputs between nano and a properly scripted (bash) fold/sed quotes. So far I like what I see in this post ->
"@MSGID: 233.tuxpower@1:154/700 2bb4e7ca".

Great news. Thanks for the confirmation. It's definitely nice to get back to nano. I mess up far too many times while in a vim session, as I'm just not used to it at all.

Regards,
Nick

... He who laughs last, thinks slowest.
--- SBBSecho 3.23-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)

Hey Nick!

This is a 'fold -s -w 69'

Great news. Thanks for the confirmation. It's definitely nice to get
back to nano. I mess up far too many times while in a vim session,
as I'm just not used to it at all.

Whereas this is with nano 'set fill 68'

Great news. Thanks for the confirmation. It's definitely nice to get
back to nano. I mess up far too many times while in a vim session,
as I'm just not used to it at all.

I had to adjust the fill to one character less in nano than in fold in order for them to produce the same result. I am guessing the same for vim.

I am more confused now than I was when I just bash scripted replies with quoted text. However I think we're on the right track if our goal is to make this more compatible with a number of editors, nano being a very good choice for most.

Life is good,
Maurice

-o o- o- -o
(\ /) /) (\
^^ ^^ ^^ ^^
... Wiþ swiþe mænige biternesse is gemenged seo swetnes þisse worulde.
With much bitterness is mingled the sweetness of this world.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice,

On Thu, Dec 05 2024 21:32:49 -0600, you wrote ..

For example, in nano, try "set fill 69" in conjunction with "set justifytrim" which removes the whitespace at the end of the lines.

For example, in nano, try "set fill 69" in conjunction with "set justifytrim" which removes the whitespace at the end of the lines.

Even though they look the same they aren't. Can you tell which is which?

Sure. The first one you trimmed the blanks at the end, and the second one they're there.

Was the second one with fold or just "set trimblanks" disabled?

Maybe the difference is that fold does (or doesn't) include the blanks in it's count, whereas nano does (or doesn't) if you have them enabled? Which one do you think is doing it incorrectly?

BTW I can't find "set justifytrim" so instead I enabled "set trimblanks" which looks to be the same end result.

Ah, seems the .nanorc in my home directory is quite a bit outdated. You are correct, they've removed 'justifytrim' at some point. :)

<Esc>:read !nano --version
GNU nano, version 8.2
(C) 2024 the Free Software Foundation and various contributors
Compiled options: --enable-utf8

Mine is the exact same, except my .nanorc is probably about as old as my last contact with the developers for the feature I was looking for. I should probably take a look at some of the new options I never knew about. :)

Regards,
Nick

... He who laughs last, thinks slowest.
--- SBBSecho 3.23-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)

Hey Nick!

Was the second one with fold or just "set trimblanks" disabled?

It was 'fold -s -w 69'. The first is nano with "set trimblanks" and "set fill 69".

Which one do you think is doing it incorrectly?

Neither, they are true to what they're called up to do. Offhand I suspect that fold is more DOSsie and it is usually one character shy of how others define the length of a string. For example FTN standards list the subject field at 72 characters when it is really 71. The 72nd character is \0, which is ye' olde string delimiter and in the case of MSGs it is a field delimiter. Offhand I'd go with fold's specifiers and have .nanorc "set fill 68" which is one less than fold but produces the same end result as 'fold -s -w 69'.

Life is good,
Maurice

-o -o o- -o
(\ (\ /) (\
^^ ^^ ^^ ^^
... Man byþ on myrgþe his magan leof; sceal þeah anra gehwylc oðrum swican.
Man in joy is dear to his kin; but they will have to part.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice,

On Fri, Dec 06 2024 18:45:27 -0600, you wrote ..

It was 'fold -s -w 69'. The first is nano with "set trimblanks" and
"set fill 69".

I knew what the first one was, but there was two possibilities for the second.

Neither, they are true to what they're called up to do. Offhand I
suspect that fold is more DOSsie and it is usually one character shy
of how others define the length of a string. For example FTN
standards list the subject field at 72 characters when it is really
71. The 72nd character is \0, which is ye' olde string delimiter and
in the case of MSGs it is a field delimiter. Offhand I'd go with
fold's specifiers and have .nanorc "set fill 68" which is one less
than fold but produces the same end result as 'fold -s -w 69'.

Ok, I suppose if nothing is wrong, then we carry on like it never happened!

Ikiwa haijavunjwa, usiirekebishe! :)

Regards,
Nick

... He who laughs last, thinks slowest.
--- SBBSecho 3.23-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)

Hey Nick!

Ok, I suppose if nothing is wrong, then we carry on like it never happened!

It's more a question of what works than what is right or wrong. Setting the width so that a quote prefix can be added will assure us that older DOS-think abandonware doesn't run over it's 79 character limit for displayed line lengths makes this quoting method superior, with or without spaces an the end. Leaving them in will make this a lossless method of quoting.

Life is good,
Maurice

-o -o o- o-
(\ (\ /) /)
^^ ^^ ^^ ^^
... Forst sceal freosan, fyr wudu meltan, eorþe growan, is brycgian.
Frost must freeze, fire melt wood, earth grow, ice form bridges.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice,

On Fri, Dec 06 2024 20:36:29 -0600, you wrote ..

It's more a question of what works than what is right or wrong.
Setting the width so that a quote prefix can be added will assure us
that older DOS-think abandonware doesn't run over it's 79 character
limit for displayed line lengths makes this quoting method superior,
with or without spaces an the end. Leaving them in will make this a lossless method of quoting.

Definitely! However, after it leaves our systems who knows what the abandonware will do with it. By the time it's quoted for the third time it's already either wrapped or text is straight up cut off the ends of the lines if they go too long.

What were they thinking?

Was it ever a standard or even 'normal' to cut text off the ends of lines when quoted? Or was that just a terrible and/or lazy implementation of quoting in whatever software was doing it?

It looks like the initial release of the "fold" command was some time in 1977, although I'm not sure when it became cross-platform.

Regards,
Nick

... He who laughs last, thinks slowest.
--- SBBSecho 3.23-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)

Hey Nick!

who knows what the abandonware will do with it.

That is why we're giving it at least 7 characters to play with. I have been known to wrap entire messages to 72 characters just to take care of their obvious handicap. Them were the good ol' days.

What were they thinking?

Strong like bull, smart like tractor?

As far as I know, quoting has never been covered in ftn standards. The tradition has become to put the initials of the quotee in the quote prefix along with the '>' character. However I think just the '>' character is more universal and makes things easier, especially when using vim or nano as the MSG editor of choice.

Life is good,
Maurice

-o -o o- -o
(\ (\ /) (\
^^ ^^ ^^ ^^
... Ich habe Eichhörnchen in meiner Hose!
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hello Maurice,

On Sat, Dec 07 2024 07:45:47 -0600, you wrote ..

That is why we're giving it at least 7 characters to play with. I
have been known to wrap entire messages to 72 characters just to take
care of their obvious handicap. Them were the good ol' days.

"Good ol' days?" I don't think much has changed.

Strong like bull, smart like tractor?

Pretty much!

As far as I know, quoting has never been covered in ftn standards.
The tradition has become to put the initials of the quotee in the
quote prefix along with the '>' character. However I think just the

' character is more universal and makes things easier, especially

when using vim or nano as the MSG editor of choice.

Yeah, but common sense would reveal that you probably shouldn't _eliminate_ random text within sentences from the original message that you are quoting. I can see entire sentences or paragraphs, but not whatever is dangling at the end of 80 columns. Darn tractors. :)

The '> ' prefix is definitely more universal, not only for FTN, but newsgroups and email as well. However, initials don't bother me much if they're there or not, as I don't usually look at them, and normally don't quote past the first level anyways.

Regards,
Nick

... He who laughs last, thinks slowest.
--- SBBSecho 3.23-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)

Hi Maurice,

On 2024-12-07 13:45:47, you wrote to Nick Boel:

As far as I know, quoting has never been covered in ftn standards.

Not a standard, but there was a proposal: http://ftsc.org/docs/fsc-0032.001


Bye, Wilfred.

--- FMail-lnx64 2.3.2.4-B20240523
* Origin: FMail development HQ (2:280/464)

Hey Wilfred!

Not a standard, but there was a proposal: http://ftsc.org/docs/fsc-0032.001

Excellent! Thanks for the heads up and I'll definetly check it out just to see if there is anything there worth the effort of coding it. At the least, proposals require some tweaking especially considering compatibility with abandonware/crippleware.

Life is good,
Maurice

o- -o -o -o
/) (\ (\ (\
^^ ^^ ^^ ^^
... Hafa ðu geleafa to lifes frumon; gewuna þar ðu wunodest.
Have faith in the creator of life; dwell where you have dwelt.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)

Hey Nick!

"Good ol' days?" I don't think much has changed.

I never did care much for newsgroups, but that had little to nothing to do with compatibility. What passes for email these days really sucks, quotes or no quotes.

The '> ' prefix is definitely more universal, not only for FTN,
but newsgroups and email as well.

Agreed. I think it would be the best way to handle this all things considered. I will definetly adjust accordingly from here on in. As for the trailing spaces I am inclined to keep them where they exist but getting rid of them is of no real concern. If I discover something that indicates differently I'll let you know.

Life is good,
Maurice

o- -o o- -o
/) (\ /) (\
^^ ^^ ^^ ^^
... Widgongel wif word gespringeð, oft hy mon wommum bilihð.
A far-wandering woman causes talk; often she is accused of sins.
--- GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu)
* Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)