I've added a couple new settings to my JamNNTPd fork (https://github.com/cnb/jamnntpd/) that I hope will fix some of the issues with spaces and quotes.

- def_nonbsp (user parameter nonbsp) for replacing UTF-8 non-breaking spaces by regular spaces.

- def_delssq (user parameter delssq) for deleting stuffed space from quoted text (only in format=flowed).

(For now, both settings are off by default for backwards compatibility.)

With both enabled, Thunderbird seems to quote better: no NBSP crap, no extra spaces in quoted Origins or other lines with leading spaces...

You can check the changes to the source code here:

https://github.com/cnb/jamnntpd/commit/e4a5ec3d519bbb5c4dff9e791ca82b80aaa237e7

Carlos

--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)

On Mon, 8 Apr 2024 01:19:26 +0200, you wrote:

With both enabled, Thunderbird seems to quote better: no NBSP crap, no extra spaces in quoted Origins or other lines with leading spaces...

So far it's looking much better than it was! :)

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Carlos,

On Sun, Apr 07 2024 23:19:26 +0000, you wrote:

--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)

While the spaces aren't added in TB, they still seem to be added with slrn.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

07 Apr 2024 21:38, you wrote to me:

--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)

While the spaces aren't added in TB, they still seem to be added with slrn.

Please check your smapi/jamnntpd console log to see if "Content-Type: ... format=flowed" appears in the header when posting a message with slrn.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

On Mon, 8 Apr 2024 18:37:26 +0200, you wrote:

Please check your smapi/jamnntpd console log to see if "Content-Type:
... format=flowed" appears in the header when posting a message with slrn.

Good call. It doesn't. So while slrn and tin most likely don't support format=flowed, smapi/jamnntpd does a good job of covering it up with the def_flowed option. :)

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

TB still seems to add an extra space while quoting the origin line, but that's probably a TB issue. You've done about all you can with the new options added.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On Mon, 8 Apr 2024 23:10:16 -0500, you wrote:

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

TB still seems to add an extra space while quoting the origin line, but that's probably a TB issue. You've done about all you can with the new options added.

HAH, nevermind. The space was removed after smapinntpd got ahold of it, slapped it around a bit, and set it straight. :)

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

09/04/2024 1:10, Nicholas Boel -> Carlos Navarro:

Please check your smapi/jamnntpd console log to see if "Content-Type:
... format=flowed" appears in the header when posting a message with slrn.

Good call. It doesn't. So while slrn and tin most likely don't support format=flowed, smapi/jamnntpd does a good job of covering it up with the def_flowed option. :)

Ok.

With newsreaders that don't support format=flowed it may be better to log in with parameter /flowed=off

Alternatively, you could set 'def_flowed off' in your server config, but then Thunderbird & Seamonkey users would have to login with /flowed=on (if they want format=flowed)

Carlos

--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)

09/04/2024 1:12, Nicholas Boel -> Nicholas Boel:

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

TB still seems to add an extra space while quoting the origin line, but
that's probably a TB issue. You've done about all you can with the new
options added.

That's just the way it works, it seems. If there are any other clients that support format=flowed it would be interesting to check if they do the same.

HAH, nevermind. The space was removed after smapinntpd got ahold of it, slapped it around a bit, and set it straight. :)

:-)

Nice to see it's working.

Carlos

--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)

On Wed, 10 Apr 2024 02:43:56 +0200, you wrote:

With newsreaders that don't support format=flowed it may be better to
log in with parameter /flowed=off

Better how? If the only thing wrong is a space before the origin line, I'm not to worried about it. At least now I know WHY it's doing it.

Alternatively, you could set 'def_flowed off' in your server config, but then Thunderbird & Seamonkey users would have to login with /flowed=on
(if they want format=flowed)

Users? The only user besides me here is Tommi, and usually only for testing purposes. He can log in however he wants. :)

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On Wed, 10 Apr 2024 03:05:28 +0200, you wrote:

That's just the way it works, it seems. If there are any other clients that support format=flowed it would be interesting to check if they do
the same.

I would imagine they do.

HAH, nevermind. The space was removed after smapinntpd got ahold of it,
slapped it around a bit, and set it straight. :)

Nice to see it's working.

Also, I realized why quotes get wrapped to the next line. It's usually something that has already been quoted with initials. TB has no idea what to do with those, so it doesn't rewrap the text (unless you hit CTRL-R).

I tried upping mailnews.wraplength to 79, and also down to 66 as suggested in some RFC that was posted by you in the past, I believe. Neither one helps. Where the default settings are now is probably the best. Fidonet style "smart quoting" sometimes just needs a bit of backspacing of the text that gets wrapped to the next line back up to the previous line it should be on.

If we were to fix that, we would probably have to get into the quoting and rewrapping part of the code in order to detect initials/smartquotes, remove them while remembering what quote level it was, rewrap the text to be quoted, and re-add the initials with the quote level (probably how Golded does it).

Either way, the current situation is definitely a lot better than it was. ;)

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

07/04/2024 20:19, Carlos Navarro -> All:

- def_delssq (user parameter delssq) for deleting stuffed space from quoted text (only in format=flowed).

After taking another look at the RFCs, I believe this is the correct approach.

I'm considering removing this experimental setting and always delete stuffed space from quotes, or at least make it on by default. Thoughts?

Carlos

--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)

10/04/2024 1:09, Nicholas Boel -> Carlos Navarro:

With newsreaders that don't support format=flowed it may be better to
log in with parameter /flowed=off

Better how? If the only thing wrong is a space before the origin line, I'm not
to worried about it. At least now I know WHY it's doing it.

Not only the Origin line, but any line that begins with one or more spaces.

Alternatively, you could set 'def_flowed off' in your server config, but
then Thunderbird & Seamonkey users would have to login with /flowed=on
(if they want format=flowed)

Users? The only user besides me here is Tommi, and usually only for testing
purposes. He can log in however he wants. :)

I mean potential users...
I'm the only user here, too (for now) :-)

Carlos

--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)

On Thu, 11 Apr 2024 17:45:36 +0200, you wrote:

After taking another look at the RFCs, I believe this is the correct approach.

I'm considering removing this experimental setting and always delete stuffed space from quotes, or at least make it on by default. Thoughts?

I think the option to toggle is still a good idea for people that aren't using clients that this is affected by. It took upwards of 20 years for us (or anyone, for that matter) to find and report this.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On Thu, 11 Apr 2024 17:59:52 +0200, you wrote:

Better how? If the only thing wrong is a space before the origin line, I'm not
too worried about it. At least now I know WHY it's doing it.

Not only the Origin line, but any line that begins with one or more spaces.

I only see it now in slrn. I don't see it in tin at all. I don't think either of them actually support format=flowed. So I think if someone has an issue, they can easily DISable it.

Users? The only user besides me here is Tommi, and usually only for testing
purposes. He can log in however he wants. :)

I mean potential users...
I'm the only user here, too (for now) :-)

I think there are only a handful of us actual fans of the software, and don't see us getting a huge surge of users any time soon. ;)

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

11 Apr 2024 18:12, you wrote to me:

After taking another look at the RFCs, I believe this is the
correct approach.

I'm considering removing this experimental setting and always
delete stuffed space from quotes, or at least make it on by
default. Thoughts?

I think the option to toggle is still a good idea for people that
aren't using clients that this is affected by.

I suspect that no clients will be affected...

For now, I'm setting 'def_delssq' to 'on' by default in my JamNNTPd fork. (I suggest you do the same in yours.)

It took upwards of 20 years for us (or anyone, for that matter) to
find and report this.

I found there was a thread about this in 2016 (re: "Line indents").

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

11 Apr 2024 18:16, you wrote to me:

Not only the Origin line, but any line that begins with one or
more spaces.

I only see it now in slrn. I don't see it in tin at all. I don't think either of them actually support format=flowed. So I think if someone
has an issue, they can easily DISable it.

I haven't used tin, but I've checked its source code and it seems it DOES support format=flowed, at least for reading.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

On Sat, 13 Apr 2024 01:35:14 +0200, you wrote:

For now, I'm setting 'def_delssq' to 'on' by default in my JamNNTPd
fork. (I suggest you do the same in yours.)

Done. Thanks for the heads up.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On Sat, 13 Apr 2024 03:01:36 +0200, you wrote:

I haven't used tin, but I've checked its source code and it seems it
DOES support format=flowed, at least for reading.

Hmm. I guess I haven't really seen it this way. I haven't been able to get unquoted lines to be full width of the screen I'm using, even with the "wrap_column 0" option used (which is supposed to wrap at the end of the screen).

I can definitely see differences between tin and slrn though, that would suggest it supported it, at least somewhat.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On 11.04.2024 10:45, Carlos Navarro wrote:

- def_delssq (user parameter delssq) for deleting stuffed space from quoted text (only in format=flowed).

After taking another look at the RFCs, I believe this is the correct approach.

I'm considering removing this experimental setting and always delete
stuffed space from quotes, or at least make it on by default. Thoughts?

Lots of fixes applied. Looks promising. Lets see.. :)

'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

On 10.04.2024 7:09, Nicholas Boel -> Carlos Navarro:

Users? The only user besides me here is Tommi, and usually only for testing purposes. He can log in however he wants. :)

:)

...
---
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

13/04/2024 1:11, Nicholas Boel -> Carlos Navarro:

I haven't used tin, but I've checked its source code and it seems it
DOES support format=flowed, at least for reading.

Hmm. I guess I haven't really seen it this way. I haven't been able to
get unquoted lines to be full width of the screen I'm using, even with
the "wrap_column 0" option used (which is supposed to wrap at the end of the screen).

I can definitely see differences between tin and slrn though, that would suggest it supported it, at least somewhat.

Maybe it has partial support. At least it displays f=f messages without extra spaces. That's nice, you don't need to set flowed=off.

Carlos

--- Mozilla Thunderbird
* Origin: cyberiada-NNTP (2:341/234.99)

Hello Carlos,

On Sat, Apr 13 2024 07:19:36 -0500, you wrote:

I can definitely see differences between tin and slrn though, that would
suggest it supported it, at least somewhat.

Maybe it has partial support. At least it displays f=f messages without extra spaces. That's nice, you don't need to set flowed=off.

I have no idea. But I've contacted support to ask for specifics on that option, so we will see if I can get any help on the matter. It's definitely one of the better text-based newsreaders on Linux that I could find.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- tin/2.6.3-20231224 ("Banff") (Linux/6.8.4-arch1-1 (x86_64))
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello, Nicholas Boel.
On 13/04/2024 13.32 you wrote:

Hello Carlos,
On Sat, Apr 13 2024 07:19:36 -0500, you wrote:

I can definitely see differences between tin and slrn though, that would
suggest it supported it, at least somewhat.

Maybe it has partial support. At least it displays f=f messages without
extra spaces. That's nice, you don't need to set flowed=off.

I have no idea. But I've contacted support to ask for specifics on that option, so we will see if I can get any help on the matter. It's definitely one of the better text-based newsreaders on Linux that I could find.

Hotdoged still doesn't seem to support flowed... :(

Regards,
Nick
... Take my advice, I don't use it anyway.
--- tin/2.6.3-20231224 ("Banff") (Linux/6.8.4-arch1-1 (x86_64))
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

--
'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

Hello Tommi,

On Sat, Apr 13 2024 16:22:26 -0500, you wrote:

Hotdoged still doesn't seem to support flowed... :(

Is that some kind of phone/tablet app? If so, I'm not interested. But you might be able to take it up with the developers?

Tin does seem to support format=flowed, as I logged in to tin's nntp mailing list and read some of the discussions held there. Some of the messages also wrapped at the end of my screen. I have yet to see that in Fidonet with this program, though. So I wonder if it's something not related to tin itself, or the stars have to align perfectly, or something. :)

Regards,
Nick

... Take my advice, I don't use it anyway.
--- tin/2.6.3-20231224 ("Banff") (Linux/6.8.5-arch1-1 (x86_64))
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello, Nicholas Boel.
On 13/04/2024 17.28 you wrote:

Hello Tommi,
On Sat, Apr 13 2024 16:22:26 -0500, you wrote:

Hotdoged still doesn't seem to support flowed... :(

Is that some kind of phone/tablet app? If so, I'm not interested. But
you might be able to take it up with the developers?

This has been abandonware for some years..



http://pics.rsh.ru/img/Screens6394_s3outx1p.jpg

---
* Origin: news://news.fidonet.fi (2:221/6.0)

Hello Tommi,

On Sat, Apr 13 2024 17:39:14 -0500, you wrote:

Is that some kind of phone/tablet app? If so, I'm not interested. But
you might be able to take it up with the developers?

This has been abandonware for some years..

http://pics.rsh.ru/img/Screens6394_s3outx1p.jpg

I understand f=f isn't supported, but does it look any better if you turn the phone horizontal?

Regards,
Nick

... Take my advice, I don't use it anyway.
--- tin/2.6.3-20231224 ("Banff") (Linux/6.8.5-arch1-1 (x86_64))
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello, Tommi Koivula.
On 13/4/24 18:22 you wrote:

Hotdoged still doesn't seem to support flowed... :(

HotdogEd, like many newsreaders, does not support format=flowed.

--
Carlos

--- HotdogEd/2.13.5 (Android; Google Android; rv:1) Hotdoged/1694692242000 Hotd
* Origin: cyberiada-NNTP (2:341/234.99)

Hello, Nicholas Boel.
On 13/04/2024 21.10 you wrote:

Hello Tommi,
On Sat, Apr 13 2024 17:39:14 -0500, you wrote:

Is that some kind of phone/tablet app? If so, I'm not interested. But
you might be able to take it up with the developers?

This has been abandonware for some years..
http://pics.rsh.ru/img/Screens6394_s3outx1p.jpg

I understand f=f isn't supported, but does it look any better if you
turn the phone horizontal?

Yes, but that was not the point. :)


--
'Tommi
---
* Origin: Linux 6.1.21-v7+ armv7l (2:221/360.0)

Hello, Carlos Navarro.
On 13/04/2024 21.21 you wrote:

Hello, Tommi Koivula.
On 13/4/24 18:22 you wrote:

Hotdoged still doesn't seem to support flowed... :(

HotdogEd, like many newsreaders, does not support format=flowed.

Which is actually quite funny, because as a ftn reader it works fine. :)

--- HotdogEd/2.13.5 (Android; Google Android; rv:1) Hotdoged/1694692242000 Hotd
* Origin: cyberiada-NNTP (2:341/234.99)

--
'Tommi
---
* Origin: Linux 6.1.21-v7+ armv7l (2:221/360.0)

Hello, Tommi Koivula.
On 13/4/24 21:35 you wrote:

HotdogEd, like many newsreaders, does not support format=flowed.

Which is actually quite funny, because as a ftn reader it works
fine. :)

In FTN, a paragraph is just a long line.

In format=flowed, a paragraph is formed by several soft-wrapped lines (except the last one). A trailing space indicates that it has been wrapped.

Check the message source (ctrl-U in TB) and highlight any paragraph to see those spaces...

--
Carlos
--- Hotdoged/2.13.5/Android
* Origin: cyberiada (2:341/234.12)

Hello, Nicholas Boel.
On 13/4/24 19:28 you wrote:

Is that some kind of phone/tablet app?

HotdogEd is a fantastic Android app that can be used both for a Fidonet point and for NNTP. Unfortunately, no longer maintained, but still works for me. In fact, it's what I mostly use to read echos.

--
Carlos

--- HotdogEd/2.13.5 (Android; Google Android; rv:1) Hotdoged/1694692242000 Hotd
* Origin: cyberiada-NNTP (2:341/234.99)

Hello, Carlos Navarro.
On 13/04/2024 21.11 you wrote:

Hello, Tommi Koivula.
On 13/4/24 21:35 you wrote:

HotdogEd, like many newsreaders, does not support format=flowed.

Which is actually quite funny, because as a ftn reader it works
fine. :)

In FTN, a paragraph is just a long line.

Yes, correct.

It would be nice to see jamnntpd to support hotdoged by not to wrap lines :)

In format=flowed, a paragraph is formed by several soft-wrapped lines (except the last one). A trailing space indicates that it has been wrapped.

So we need to add user option /nowrap to allow long lines?


--
Tommi
--- Hotdoged/2.13.5/Android
* Origin: ......... (2:221/1.2)

14 Apr 2024 06:56, you wrote to me:

It would be nice to see jamnntpd to support hotdoged by not to wrap
lines :)

Yes, for HotdogEd or any newsreader showing less than 72 chars per line.

So we need to add user option /nowrap to allow long lines?

Will do. ;-)

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

Hello Tommi,

On Sun, 14 Apr 2024 02:35:38 +0300, you wrote:

Yes, but that was not the point. :)

My point was to find you a simple fix for your abandonware. :)

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Carlos,

On Mon, Apr 15 2024 18:31:50 -0500, you wrote:

It would be nice to see jamnntpd to support hotdoged by not to wrap
lines :)

Yes, for HotdogEd or any newsreader showing less than 72 chars per line.

So we need to add user option /nowrap to allow long lines?

Will do. ;-)

Not sure I'm understanding this correctly.

Wouldn't '/nowrap' just be 'flowed=on', which would then leave the formatting to HotdogEd, which doesn't seem to be doing so properly?

Or are you looking for some kind of option for HotdogEd users to be able set some kind of forced wrapping for it's own display?

Regards,
Nick

... Take my advice, I don't use it anyway.
--- tin/2.6.3-20231224 ("Banff") (Linux/6.8.7-arch1-1 (x86_64))
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Nicholas Boel wrote:

TK>> It would be nice to see jamnntpd to support hotdoged by not
TK>> to wrap lines :)

CN> Yes, for HotdogEd or any newsreader showing less than 72
CN> chars per line.

TK>> So we need to add user option /nowrap to allow long lines?

CN> Will do. ;-)

Not sure I'm understanding this correctly.

Wouldn't '/nowrap' just be 'flowed=on', which would then leave the formatting to HotdogEd, which doesn't seem to be doing so properly?

Or are you looking for some kind of option for HotdogEd users to be
able set some kind of forced wrapping for it's own display?

If I get it right, with 'flowed=on' jamnntpd will always wrap the long
lines, but adding a space to the end of the wrapped line.

My idea was to allow sending the long line from fidonet unwrapped so
that the news client would wrap it. Just like ftn editors do.

I dont know how it would work. :)

'Tommi

---
* Origin: jamnntpd/lnx (2:221/1.0)

20 Apr 2024 09:21, you wrote to me:

Not sure I'm understanding this correctly.

Wouldn't '/nowrap' just be 'flowed=on', which would then leave the formatting to HotdogEd, which doesn't seem to be doing so properly?

HotdogEd (like may other newsreaders) doesn't support format=flowed, so it doesn't join the wrapped lines with trailing space.

Here's an example. This is a normal paragraph, a long line with a CR+LF (NNTP) or CR (FTN) at the end:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

The same paragraph but with format=flowed (wrapped at 40 instead of the usual 72):

Lorem ipsum dolor sit amet, consectetur[SP]
adipiscing elit, sed do eiusmod tempor[SP]
incididunt ut labore et dolore magna[SP]
aliqua. Ut enim ad minim veniam, quis[SP]
nostrud exercitation ullamco laboris[SP]
nisi ut aliquip ex ea commodo consequat.

[SP] is a regular space (ASCII 32)

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

20 Apr 2024 19:32, you wrote to Nicholas Boel:

If I get it right, with 'flowed=on' jamnntpd will always wrap the long lines, but adding a space to the end of the wrapped line.

Exactly.

My idea was to allow sending the long line from fidonet unwrapped so
that the news client would wrap it. Just like ftn editors do.

If you want to experiment, you can get a similar result if you set WRAP_WIDTH to 997. Only paragraphs longer than that will be wrapped.

I dont know how it would work. :)

It works (in fact, other NNTP servers do that), but there are issues with some newsreaders, e.g. Thunderbird. A quoted paragraph is not wrapped, so it becomes a long line prefixed by just one ">". This doesn't work well with all FTN/BBS software. (See my "long line test" thread in FIDOTEST.)

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

Hello Carlos,

On Sat, 20 Apr 2024 23:38:00 +0200, you wrote:

Wouldn't '/nowrap' just be 'flowed=on', which would then leave the
formatting to HotdogEd, which doesn't seem to be doing so properly?

HotdogEd (like may other newsreaders) doesn't support format=flowed, so
it doesn't join the wrapped lines with trailing space.

So, if HotdogEd doesn't support format=flowed, wouldn't it be better to use 'flowed=off'?

Or while using HotdogEd with flowed=off, it still wraps at the 72/79 columns set by jam/smapinntpd, which then HotdogEd would still wrap the text early because it doesn't have that many columns on the screen?

Here's an example. This is a normal paragraph, a long line with a CR+LF (NNTP) or CR (FTN) at the end:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

The same paragraph but with format=flowed (wrapped at 40 instead of the usual 72):

Lorem ipsum dolor sit amet, consectetur[SP]
adipiscing elit, sed do eiusmod tempor[SP]
incididunt ut labore et dolore magna[SP]
aliqua. Ut enim ad minim veniam, quis[SP]
nostrud exercitation ullamco laboris[SP]
nisi ut aliquip ex ea commodo consequat.

[SP] is a regular space (ASCII 32)

Both of these look fine on Thunderbird (with flowed=on), as well as tin (with flowed on and off), and slrn (with flowed on), and I'm still unsure format=flowed is supported in either of the last two mentioned.

Maybe tin and slrn can deal with incoming format=flowed, but just don't post that way..?

So is it a HotdogEd problem that you're looking to come up with a work around for, specifically?

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Tommi,

On Sun, 21 Apr 2024 00:32:44 +0300, you wrote:

If I get it right, with 'flowed=on' jamnntpd will always wrap the long lines, but adding a space to the end of the wrapped line.

So you're saying jamnntpd takes the message stored in the message base that is not wrapped, and wraps the long lines when sending it to a client?

I'm looking at the message directly that I'm replying to in my jamnntpd.jdt file, and the lines are long. I can resize my PuTTY window while viewing the JAM file and it even reflows.

My idea was to allow sending the long line from fidonet unwrapped so
that the news client would wrap it. Just like ftn editors do.

That's what I would expect to happen also. I didn't realize it was doing something different, especially by the way it looks directly in the message base.


Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Carlos,

On Sat, Apr 20 2024 17:06:16 -0500, you wrote:

It works (in fact, other NNTP servers do that), but there are issues
with some newsreaders, e.g. Thunderbird. A quoted paragraph is not wrapped, so it becomes a long line prefixed by just one ">". This
doesn't work well with all FTN/BBS software. (See my "long line test" thread in FIDOTEST.)

I think the last time I saw this was when Tommi quoted something with HotdogEd. Is this what happens when he quotes a long line message with 'flowed=on'?
--- tin/2.6.3-20231224 ("Banff") (FreeBSD/15.0-CURRENT (amd64))
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Carlos Navarro wrote:

TK> If I get it right, with 'flowed=on' jamnntpd will always wrap
TK> the long lines, but adding a space to the end of the wrapped
TK> line.

Exactly.

TK> My idea was to allow sending the long line from fidonet
TK> unwrapped so that the news client would wrap it. Just like
TK> ftn editors do.

If you want to experiment, you can get a similar result if you set WRAP_WIDTH to 997. Only paragraphs longer than that will be wrapped.

This is exactly what I did once in the past. :) The combination of
WRAP_WIDTH 997 and FLOWED OFF was a pretty good choice.

It works (in fact, other NNTP servers do that), but there are
issues with some newsreaders, e.g. Thunderbird. A quoted paragraph
is not wrapped, so it becomes a long line prefixed by just one ">".
This doesn't work well with all FTN/BBS software. (See my "long
line test" thread in FIDOTEST.)

Yes. It needs a little manual works.

'Tommi

---
* Origin: jamnntpd/lnx (2:221/1.0)

On 20.04.2024 17:06, Carlos Navarro wrote:

It works (in fact, other NNTP servers do that), but there are issues
with some newsreaders, e.g. Thunderbird. A quoted paragraph is not wrapped, so it becomes a long line prefixed by just one ">". This
doesn't work well with all FTN/BBS software. (See my "long line
test" thread in FIDOTEST.)

In thi case selecting the quoted text and pressing Ctrl-R in Thunderbird might help.

'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

On 20.04.2024 16:52, Nicholas Boel wrote:

So, if HotdogEd doesn't support format=flowed, wouldn't it be better to use 'flowed=off'?

Or while using HotdogEd with flowed=off, it still wraps at the 72/79 columns set by jam/smapinntpd, which then HotdogEd would still wrap the text early because it doesn't have that many columns on the screen?

In my phone screen the width is about 58 characters. So it wraps first at 58, then at 79. :(

The weird thing is that using a "real" nntp server this is not happening...

'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

Hello, Tommi Koivula.
On 21/04/2024 7.57 you wrote:

On 20.04.2024 16:52, Nicholas Boel wrote:

So, if HotdogEd doesn't support format=flowed, wouldn't it be better to
use 'flowed=off'?
Or while using HotdogEd with flowed=off, it still wraps at the 72/79
columns set by jam/smapinntpd, which then HotdogEd would still wrap the
text early because it doesn't have that many columns on the screen?

In my phone screen the width is about 58 characters. So it wraps first at 58, then at 79. :(
The weird thing is that using a "real" nntp server this is not happening...
'Tommi
---
* Origin: smapinntpd/lnx (2:221/1.0)

Quote test hotdoged ftn.

--- Hotdoged/2.13.5/Android
* Origin: ......... (2:221/1.2)

Hello, Tommi Koivula.
On 21/04/2024 4.57 you wrote:

On 20.04.2024 16:52, Nicholas Boel wrote:

So, if HotdogEd doesn't support format=flowed, wouldn't it be better to
use 'flowed=off'?
Or while using HotdogEd with flowed=off, it still wraps at the 72/79
columns set by jam/smapinntpd, which then HotdogEd would still wrap the
text early because it doesn't have that many columns on the screen?

In my phone screen the width is about 58 characters. So it wraps first
at 58, then at 79. :(
The weird thing is that using a "real" nntp server this is not happening...
'Tommi
---
* Origin: smapinntpd/lnx (2:221/1.0)

Quote test hotdoged nntp.

---
* Origin: smapinntpd/lnx (2:221/1.0)

Hello Tommi,

On Sun, 21 Apr 2024 12:57:30 +0300, you wrote:

In my phone screen the width is about 58 characters. So it wraps first
at 58, then at 79. :(

The weird thing is that using a "real" nntp server this is not happening...

If you look at the code for the "real" nntp server, can you make anything out of it in regards to differences in wrap settings (or if there is none at all)?

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Tommi,

On Sun, 21 Apr 2024 14:09:26 GMT, you wrote:

So, if HotdogEd doesn't support format=flowed, wouldn't it be
better to use 'flowed=off'?

Or while using HotdogEd with flowed=off, it still wraps at the 72/79
columns set by jam/smapinntpd, which then HotdogEd would still
wrap the text early because it doesn't have that many columns on the
screen?

In my phone screen the width is about 58 characters. So it wraps
first at 58, then at 79. :(

The weird thing is that using a "real" nntp server this is not
happening...

Quote test hotdoged WendzelNNTPd.

Both of your quotes went way past 79 characters. I had to reflow them manually so they looked ok. I didn't bother with CTRL-R in TB because they were all mashed together with initials so I figured it would be worse.

So it seems that when you write with a format=flowed newsreader (ie: Thunderbird), it is indeed one long line (or at least that's how it is stored in the message base, and shown to another format=flowed client. Then when quoted by HotdogEd, it remains one long line (which shouldn't happen to quoted text). I think quoted text should probably still be reflowed to within the 72-79 character limit to stay backwards compatible - Especially when adding initials, etc. However, the newly written text can be one long line in which the next reader's software would fit it into their screen dimentions.

I think jam/smapinntpd reflows the quoted text until it can't. Every time a quote is quoted again, the quote characters + initials keep moving to the right, lengthening the original line, and then when there is not enough space left, it will wrap some of the text on to the next line, without reflowing it, because I don't think it knows how to reflow initials. This may just be a smartquote issue, or maybe not. Just what I've noticed.

Not sure why HotdogEd is wrapping at 58 and 79, though. Could that just be a screen length issue in HotdogEd, since you did mention when you turn the screen sideways it displays better.

Just wondering if HotdogEd is defaulted to wrapping at 79 characters, but on a phone turned vertical you don't actually have that many characters. Have you tried HotdogEd on a tablet or something with a bigger screen?

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Nicholas,

On Sun, 21 Apr 2024 12:04:42 -0500, you wrote:

Just wondering if HotdogEd is defaulted to wrapping at 79 characters,
but on a phone turned vertical you don't actually have that many characters. Have you tried HotdogEd on a tablet or something with a
bigger screen?

Expanding on this, while using TB, I have two screenshots:

https://pharcyde.org/tb-over80.png

This one is basically my normal viewing size. Keep in mind before I replied to it I reflowed the quoted text manually so it didn't look bad.

https://pharcyde.org/tb-under80.png

Here I resized the window to under 80 characters. Notice the newly written text is still flowed to fit the screen, however the quoted text looks much like your HotdogEd screenshots. Quoted text beginning with any kind of quote character (including initials) can not be reflowed without actually removing the quote characters first. I don't think jam/smapinntpd does this.

Is it only quoted text that looks bad in HotdogEd?

Does newly written text display flowed to the size of the screen in HotdogEd?

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla Thunderbird
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hi Nicholas.

21 Apr 24 06:44, you wrote to me:

Hello Tommi,

On Sun, 21 Apr 2024 12:57:30 +0300, you wrote:

In my phone screen the width is about 58 characters. So it wraps first
at 58, then at 79. :(

The weird thing is that using a "real" nntp server this is not
happening...

If you look at the code for the "real" nntp server, can you make anything out
of it in regards to differences in wrap settings (or if there is none at all)?

I compiled wendzelnntpd, but I haven't read the code, yet.

'Tommi

--- GoldED+/LNX 1.1.5-b20240309
* Origin: Linux 6.1.21-v7+ armv7l (2:221/6.26)

Hello Tommi,

On Sun, Apr 21 2024 17:16:10 -0500, you wrote:

If you look at the code for the "real" nntp server, can you make

anything out

of it in regards to differences in wrap settings (or if there is

none at all)?

I compiled wendzelnntpd, but I haven't read the code, yet.

If you notice above, even Golded seems to quote longer than 80 character lines not so well. But since Golded displays them long as well, you don't really notice it. This seems to be exactly what jam/smapinntpd does also, and probably has to do with format=flowed text.

--- GoldED+/LNX 1.1.5-b20240309

Regards,
Nick

... Take my advice, I don't use it anyway.
--- tin/2.6.3-20231224 ("Banff") (FreeBSD/15.0-CURRENT (amd64))
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On 21.04.2024 20:29, Nicholas Boel wrote:

On Sun, Apr 21 2024 17:16:10 -0500, you wrote:

If you look at the code for the "real" nntp server, can you make

anything out

of it in regards to differences in wrap settings (or if there is

none at all)?

I compiled wendzelnntpd, but I haven't read the code, yet.

If you notice above, even Golded seems to quote longer than 80 character lines not so well. But since Golded displays them long as well, you
don't really notice it. This seems to be exactly what jam/smapinntpd
does also, and probably has to do with format=flowed text.

--- GoldED+/LNX 1.1.5-b20240309

Golded is smart. Hotdoged is pretty stupid with quotes. ;)

Anyways, it is always up to the author of the message how to format his/her message.

'Tommi

---
* Origin: jamnntpd/lnx (2:221/1.0)

Hello Nicholas,

On Sun, Apr 21 2024 17:29:28 +0000, you wrote:

Just wondering if HotdogEd is defaulted to wrapping at 79 characters,
but on a phone turned vertical you don't actually have that many
characters. Have you tried HotdogEd on a tablet or something with a
bigger screen?

Replying to this message as a test. Keep in mind the message I'm replying to was done with TB and flowed=on. Everything here looks ok in slrn and nano using flowed=off.

Here I resized the window to under 80 characters. Notice the newly
written text is still flowed to fit the screen, however the quoted text looks much like your HotdogEd screenshots. Quoted text beginning with
any kind of quote character (including initials) can not be reflowed without actually removing the quote characters first. I don't think jam/smapinntpd does this.

I'm guessing the spaces at the end of the above quoted lines have been removed, now that I'm using flowed=off.

Is it only quoted text that looks bad in HotdogEd?

Does newly written text display flowed to the size of the screen in HotdogEd?

The line above is now 79 characters with the addition of the single quote character and space. The last word (or words) will most likely be wrapped to the next line without a quote character when the initials are added - when viewed in flowed=off and/or in an 80 character wide terminal/client.

Either way, I don't think the issues are specific to HotdogEd, except the fact that HotdogEd adds another wrench into the mix by only being ~58 characters wide. So this is noticable much more often. :(

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (FreeBSD)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Tommi,

On Sun, Apr 21 2024 22:39:54 +0000, you wrote:

Golded is smart. Hotdoged is pretty stupid with quotes. ;)

Not sure how smart it is when quoted text shouldn't go past 80 characters. But yes, Golded is much smarter than most things when it comes to FTN messaging, since that's what it was made specifically for.

Anyways, it is always up to the author of the message how to format his/her message.

Agreed, however.. quoted text should remain less than 80 columns (whether it's the first time quoted, or the 7th time), and we have clearly seen that it doesn't do so in multiple applications, including our beloved Golded.

I'm just wondering if making a hack/workaround for HotdogEd, which is now abandonware - and won't actually fix the problem - is the best idea here.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (FreeBSD)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

21 Apr 2024 07:40, you wrote to me:

If you want to experiment, you can get a similar result if you set
WRAP_WIDTH to 997. Only paragraphs longer than that will be
wrapped.

This is exactly what I did once in the past. :) The combination of WRAP_WIDTH 997 and FLOWED OFF was a pretty good choice.

It works (in fact, other NNTP servers do that), but there are
issues with some newsreaders, e.g. Thunderbird. A quoted paragraph
is not wrapped, so it becomes a long line prefixed by just one
">". This doesn't work well with all FTN/BBS software. (See my
"long line test" thread in FIDOTEST.)

Yes. It needs a little manual works.

I've tested this again, and it seems that TB displays and quotes long lines and long quotes properly with flowed=on. Maybe I did my previous tests with flowed=off, not sure. I'll need to test more...

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

20 Apr 2024 11:52, you wrote to me:

Wouldn't '/nowrap' just be 'flowed=on', which would then leave
the formatting to HotdogEd, which doesn't seem to be doing so
properly?

HotdogEd (like may other newsreaders) doesn't support
format=flowed, so it doesn't join the wrapped lines with trailing
space.

So, if HotdogEd doesn't support format=flowed, wouldn't it be better
to use 'flowed=off'?

In principle it would be better, like with any newsreader that doesn't support f=f, so that stuffed spaces are not displayed. Other than that, there should be no difference.

In HotdogEd it doesn't really matter, as it doesn't display consecutive spaces e.g. used for indentation (you can't view ASCII art properly unless you select "View raw article").

Or while using HotdogEd with flowed=off, it still wraps at the 72/79 columns set by jam/smapinntpd, which then HotdogEd would still wrap
the text early because it doesn't have that many columns on the
screen?

Yes, but it does the same with both flowed off and on (format=flowed and format=fixed look almost identical on readers that don't support f=f). If you use it in horizontal view, or on a larger screen like a tablet, it looks better.

Both of these look fine on Thunderbird (with flowed=on), as well as
tin (with flowed on and off), and slrn (with flowed on), and I'm still unsure format=flowed is supported in either of the last two mentioned.

I think we had seen that tin does support f=f, at least it removed stuffed spaces. Does it wrap paragraphs at more than 72 chars, or are they adjusted to the screen width?

Also, what about slrn?

Maybe tin and slrn can deal with incoming format=flowed, but just
don't post that way..?

It may be that they send paragraphs as long lines, instead of breaking them into several lines with soft-wrapping trailing spaces as in format=flowed. Smapi/JamNNTPd properly handles both formats when posting to the messagebase.

So is it a HotdogEd problem that you're looking to come up with a work around for, specifically?

No, it may be good for other newsreaders too. If I'm not mistaken, Smapi/JamNNTPd would work like other NNTP servers do.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

21 Apr 2024 12:29, you wrote to Tommi Koivula:

If you notice above, even Golded seems to quote longer than 80
character lines not so well.

Looks like Tommi has set QUOTEMARGIN to 80-something in his GoldEd config...

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

Hello Carlos,

On Mon, Apr 22 2024 00:12:40 +0000, you wrote:

If you notice above, even Golded seems to quote longer than 80
character lines not so well.

Looks like Tommi has set QUOTEMARGIN to 80-something in his GoldEd config...

I'm willing to bet Tommi doesn't even have the option set/overridden from default. I've noticed this in Golded plenty of times in the past as well, and I don't use that option in my config, either.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (FreeBSD)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Carlos,

On Mon, Apr 22 2024 00:08:32 +0000, you wrote:

Or while using HotdogEd with flowed=off, it still wraps at the 72/79
columns set by jam/smapinntpd, which then HotdogEd would still wrap
the text early because it doesn't have that many columns on the
screen?

Yes, but it does the same with both flowed off and on (format=flowed and format=fixed look almost identical on readers that don't support f=f).
If you use it in horizontal view, or on a larger screen like a tablet,
it looks better.

Which is why I'm wondering if the wrap is set in HotdogEd for 79 characters by default. Then it would obviously have that issue when using a phone with only ~58 character width available.

I think we had seen that tin does support f=f, at least it removed
stuffed spaces. Does it wrap paragraphs at more than 72 chars, or are
they adjusted to the screen width?

I tested tin on the tin nntp server that contained very old messages. However, this was the only time I saw paragraphs adjusted to the screen width. Anything that has come through jam/smapinntpd has been wrapped at 72-79 characters.

Also, what about slrn?

I have never seen paragraphs adjusted to screen width with slrn, BUT I haven't tried anything else besides jam/smapinntpd with it, either. I will have to test that and see.

It may be that they send paragraphs as long lines, instead of breaking them into several lines with soft-wrapping trailing spaces as in format=flowed. Smapi/JamNNTPd properly handles both formats when posting to the messagebase.

So is it a HotdogEd problem that you're looking to come up with a work
around for, specifically?

No, it may be good for other newsreaders too. If I'm not mistaken, Smapi/JamNNTPd would work like other NNTP servers do.

I think with what I just described above (where I've seen screen width paragraphs outside of jam/smapinntpd), I see now where you guys are pointing out the difference against a "real" NNTP server.

Some clients probably don't understand the 'soft-wrapping trailing spaces', or don't care to put them back together to re-form long lines, but can handle long lines themselves just fine. Am I understanding what you are describing here, now?

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (FreeBSD)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

21 Apr 2024 14:22, you wrote to me:

Looks like Tommi has set QUOTEMARGIN to 80-something in his
GoldEd config...

I'm willing to bet Tommi doesn't even have the option set/overridden
from default. I've noticed this in Golded plenty of times in the past
as well, and I don't use that option in my config, either.

:-m I don't have that option set and quotes are wrapped at 75 (the default, if I'm not mistaken).

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

Hello Carlos,

On Mon, Apr 22 2024 00:08:32 +0000, you wrote:

Also, what about slrn?

I can now confirm via news.tin.org, slrn is also able to utilize the entire screen width - when NOT connecting to a jam/smapinntpd server.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (FreeBSD)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Carlos,

On Mon, Apr 22 2024 00:46:36 +0000, you wrote:

I'm willing to bet Tommi doesn't even have the option set/overridden
from default. I've noticed this in Golded plenty of times in the past
as well, and I don't use that option in my config, either.

:-m I don't have that option set and quotes are wrapped at 75 (the default, if I'm not mistaken).

It's also possible you just never noticed, because as long as your current screen width can keep it on that line, it will. I've also seen this in all three of the newsreaders I use here.

Another thing I noticed while visiting the tin newsgroup.. _none_ of the posts I saw, including the ones that actually fit my entire screen width, were labeled with 'Content-Type: format=flowed'. I think Tommi mentioned this with his other nntp server also.

I'm almost wondering if we don't get rid of the 'flowed' option completely, and let the client newsreaders decide what they want and can do. It may take quite a bit more work than just that, but.. it's an idea.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (FreeBSD)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Carlos,

On Sun, Apr 21 2024 19:48:10 +0000, you wrote:

I can now confirm via news.tin.org, slrn is also able to utilize the entire screen width - when NOT connecting to a jam/smapinntpd server.

I spun up Synchronet's nntp service to compare apples and oranges. Now slrn displays single long lines, which wraps at screen width. However, when quoting the single long line you get the above result. And this:

Content-Type: text/plain; charset=UTF-8

* Note no "format=flowed" on there. This seems to be the same results found in Tommi's Wendzelnntp or whatever it was.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- SBBSecho 3.20-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (1:154/700)

21 Apr 2024 14:32, you wrote to me:

Yes, but it does the same with both flowed off and on
(format=flowed and format=fixed look almost identical on readers
that don't support f=f). If you use it in horizontal view, or on
a larger screen like a tablet, it looks better.

Which is why I'm wondering if the wrap is set in HotdogEd for 79 characters by default. Then it would obviously have that issue when
using a phone with only ~58 character width available.

No. It's just that it doesn't support f=f's soft wraps. A "real" long line is wrapped at screen width.

I think we had seen that tin does support f=f, at least it
removed stuffed spaces. Does it wrap paragraphs at more than 72
chars, or are they adjusted to the screen width?

I tested tin on the tin nntp server that contained very old messages. However, this was the only time I saw paragraphs adjusted to the
screen width. Anything that has come through jam/smapinntpd has been wrapped at 72-79 characters.

So it has partial f=f support, as it seems it doesn't recognize soft wraps.

So is it a HotdogEd problem that you're looking to come up with
a work around for, specifically?

No, it may be good for other newsreaders too. If I'm not
mistaken, Smapi/JamNNTPd would work like other NNTP servers do.

I think with what I just described above (where I've seen screen width paragraphs outside of jam/smapinntpd), I see now where you guys are pointing out the difference against a "real" NNTP server.

Some clients probably don't understand the 'soft-wrapping trailing spaces', or don't care to put them back together to re-form long
lines, but can handle long lines themselves just fine. Am I
understanding what you are describing here, now?

Yes!
Thunderbird and Seamonkey do, but most others don't.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

09 Apr 2024 18:23, you wrote to me:

I tried upping mailnews.wraplength to 79, and also down to 66 as
suggested in some RFC that was posted by you in the past, I believe. Neither one helps. Where the default settings are now is probably the best. Fidonet style "smart quoting" sometimes just needs a bit of backspacing of the text that gets wrapped to the next line back up to
the previous line it should be on.

I also did several tests and couldn't find anything that didn't have issues.

If we were to fix that, we would probably have to get into the quoting
and rewrapping part of the code in order to detect
initials/smartquotes, remove them while remembering what quote level
it was, rewrap the text to be quoted, and re-add the initials with the quote level (probably how Golded does it).

It might be done in different ways, but yes, I think that the solution would be that Smapi/JamNNTPd re-wraps FTN-style quotes to 72 chars or less when sending them to the client.

The alternative would be making clients support Fido-quotes. But this seems more difficult... :-)

BTW, HotdogEd does. You can select NNTP-style (no initials) or FTN-style quoting.

There was an old, experimental Thunderbird addon for this, FTNQuoter, but AFAIK it only worked for ancient TB versions...

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

21 Apr 2024 17:49, you wrote to All:

I can now confirm via news.tin.org, slrn is also able to utilize the
entire screen width - when NOT connecting to a jam/smapinntpd
server.

I spun up Synchronet's nntp service to compare apples and oranges. Now slrn displays single long lines, which wraps at screen width. However, when quoting the single long line you get the above result.

Yup. GoldEd, HotdogEd, WinPoint and others display (and re-quote) that long quote just fine. But other FTN/BBS programs don't. That's what I mentioned in another message.

And this:

Content-Type: text/plain; charset=UTF-8

* Note no "format=flowed" on there. This seems to be the same results found in Tommi's Wendzelnntp or whatever it was.

As expected. SBBS's NNTP server does not use format=flowed.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

Hello Carlos,

On Tue, Apr 23 2024 19:46:04 +0000, you wrote:

No. It's just that it doesn't support f=f's soft wraps. A "real" long
line is wrapped at screen width.

Yes, and then ends up with only one quote character before the first line of the paragraph?

I tested tin on the tin nntp server that contained very old messages.
However, this was the only time I saw paragraphs adjusted to the
screen width. Anything that has come through jam/smapinntpd has been
wrapped at 72-79 characters.

So it has partial f=f support, as it seems it doesn't recognize soft wraps.

Yes, this is true for both tin and slrn. However, there is an option in both to remove trailing spaces at the end of lines. So, it seems it may have been known about, however, there is no function to re-flow the lines.

Some clients probably don't understand the 'soft-wrapping trailing
spaces', or don't care to put them back together to re-form long
lines, but can handle long lines themselves just fine. Am I
understanding what you are describing here, now?

Yes!
Thunderbird and Seamonkey do, but most others don't.

I've been noticing this, also. This has become kind of a pain in the arse. 2 nntp servers and 4 clients, and everything acts differently in combination. :(

So, I think the real way nntp servers handle it is to not mess with the paragraph at all. One long line. However, there is (or used to be) nntp "etiquette". Slrn and tin both warn you that what you wrote is too long, and that it should be shortened with your editor to <80 columns. Basically they're telling you to hard wrap with your editor (which is something I won't do). ;)

Jam/Smapinntpd has helped this quite a bit, so that most any editor can be used and not really affect the outcome.

So if HotdogEd is your only current worry, maybe you could add some kind of user option to change WRAP_WIDTH to 50 and LINE_WIDTH to 58 or something in order to fit on your phone screen. But then again, it's abandonware. lol

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Carlos,

On Tue, Apr 23 2024 19:57:42 +0000, you wrote:

09 Apr 2024 18:23, you wrote to me:

I also did several tests and couldn't find anything that didn't have issues.

Yes, if one issue got better, another one got worse. :)

If we were to fix that, we would probably have to get into the quoting
and rewrapping part of the code in order to detect
initials/smartquotes, remove them while remembering what quote level
it was, rewrap the text to be quoted, and re-add the initials with the
quote level (probably how Golded does it).

It might be done in different ways, but yes, I think that the solution would be that Smapi/JamNNTPd re-wraps FTN-style quotes to 72 chars or
less when sending them to the client.

Yeah, then at that point I don't think it matters what the newly written text looks like.

The alternative would be making clients support Fido-quotes. But this seems more difficult... :-)

Yeah right. :D

BTW, HotdogEd does. You can select NNTP-style (no initials) or FTN-style quoting.

So does tin, you can specify the 'quote prefix' to use, and %I is a code for initials, so _%I>_ does the trick. When I use tin I use "smartquote=off". However, I just noticed that when tin actually does fit text to the screen size, it doesn't wrap at word boundaries. So it will wrap right in the middle of a word. Ugh. I don't think there is light at the end of the tunnel any time soon.

Then slrn doesn't have support for initials, but does wrap at word boundaries. So as of right now slrn with "smartquote=on" is looking better and better as far as a console newsreader goes. Neither one really compares to Thunderbird, though. ;)

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Carlos,

On Tue, Apr 23 2024 20:07:08 +0000, you wrote:

* Note no "format=flowed" on there. This seems to be the same results
found in Tommi's Wendzelnntp or whatever it was.

As expected. SBBS's NNTP server does not use format=flowed.

So does that mean the NNTP server Tommi is using also does not use f=f?

I've also been looking through as many FAQs as I can find on inn (InterNetNews) which is/was/might+still+be a very popular news server, and don't see much of anything mentioned about format=flowed at all.

Seems to me f=f is/was more of an email thing.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On 21.04.2024 19:22, Nicholas Boel wrote:

On Mon, Apr 22 2024 00:12:40 +0000, you wrote:

If you notice above, even Golded seems to quote longer than 80
character lines not so well.

Looks like Tommi has set QUOTEMARGIN to 80-something in his GoldEd

config...

I'm willing to bet Tommi doesn't even have the option set/overridden

You may win or lose. I *do* have that setting in some of my golded's. :)

'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

Hello Tommi,

On Sat, Apr 27 2024 14:40:10 +0000, you wrote:

I'm willing to bet Tommi doesn't even have the option set/overridden

You may win or lose. I *do* have that setting in some of my golded's. :)

Ok, but do you have it set to 80+? I think that's where we were going with that topic.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Accession,

On Sat, 27 Apr 2024 07:52:20 -0500, I wrote to Tommi Koivula:

I'm willing to bet Tommi doesn't even have the option set/overridden

You may win or lose. I *do* have that setting in some of my golded's.
:)

Ok, but do you have it set to 80+? I think that's where we were going with that topic.

Here is a perfect example. I have set "quotemargin 75" in my golded.conf, and the line above is still wrapped by golded at 79. Now, probably when this gets re-quoted by something like Jam/Smapinntpd that uses WRAP_WIDTH 72 and LINE_WIDTH 79, there may be an issue.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- GoldED+/LNX 1.1.5-b20240309
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Nicholas Boel wrote:

NB>> I'm willing to bet Tommi doesn't even have the option
NB>> set/overridden

TK> You may win or lose. I *do* have that setting in some of my
TK> golded's. :)

Ok, but do you have it set to 80+? I think that's where
we were going with that topic.

In this echo, I dont think so. Maybe 79. I would have to read back
which Golded I used to write that particular message.

'Tommi

---
* Origin: rbb.fidonet.fi - Lake Ylo - Finland (2:221/6.6)

Hello Nicholas,

On Sat, Apr 27 2024 18:09:00 +0000, you wrote:

Hello Accession,

On Sat, 27 Apr 2024 07:52:20 -0500, I wrote to Tommi Koivula:

I'm willing to bet Tommi doesn't even have the option set/overridden

You may win or lose. I *do* have that setting in some of my golded's.
:)

Ok, but do you have it set to 80+? I think that's where we were going with
that topic.

And now with slrn, the above line is wrapped at 80 since another quote character has been added. Let's see if it wraps one word to the next line, unquoted.

Here is a perfect example. I have set "quotemargin 75" in my
golded.conf, and the line above is still wrapped by golded at 79. Now, probably when this gets re-quoted by something like Jam/Smapinntpd that uses WRAP_WIDTH 72 and LINE_WIDTH 79, there may be an issue.

This text here has been wrapped under 75 characters, though.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Nicholas,

On Sat, Apr 27 2024 18:16:54 +0000, you wrote:

Ok, but do you have it set to 80+? I think that's where we were

going with

that topic.

And this is what you end up with. However, Golded will display this long line just fine.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Accession,

On Sat, 27 Apr 2024 08:16:54 -0500, I wrote to me:

Ok, but do you have it set to 80+? I think that's where we were going
with that topic.

And here, Golded reflowed the quoted text by moving "with" to the next line, and re-added the quote characters, wrapping at 76 characters now.

So, it definitely doesn't stay strict to the set 'quotemargin 75' but still, Golded handles this better than anything else we've been testing. Either way, that is what I've been trying to describe.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- GoldED+/LNX 1.1.5-b20240309
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Nicholas,

On Sat, Apr 27 2024 18:09:00 +0000, you wrote:

Ok, but do you have it set to 80+? I think that's where we were going with
that topic.

Test message with WRAP_WIDTH 72, LINE_WIDTH 80.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hello Nicholas,

On Sat, Apr 27 2024 18:35:00 +0000, you wrote:

Ok, but do you have it set to 80+? I think that's where we were going with
that topic.

Test message with WRAP_WIDTH 72, LINE_WIDTH 80.

.. and it doesn't matter, because Jam/Smapinntpd doesn't reflow already quoted text. At some point it will mess it up.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- slrn/pre1.0.4-9 (Linux)
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

23 Apr 2024 19:10, you wrote to me:

No. It's just that it doesn't support f=f's soft wraps. A "real"
long line is wrapped at screen width.

Yes, and then ends up with only one quote character before the first
line of the paragraph?

No, HotdogEd reflows quotes mostly fine when displaying them, with the quote prefix (with or without initials) at every line.

So if HotdogEd is your only current worry, maybe you could add some
kind of user option to change WRAP_WIDTH to 50 and LINE_WIDTH to 58 or something in order to fit on your phone screen. But then again, it's abandonware. lol

I'm not thinking only about HotdogEd, but any reader to be used with small screens (e.g. PhoNews, and I guess NewsTap on iOS)

HotdogEd can have very different number of columns depending on the device resolution and the text size you specify in its settings. Long lines would work better for all.

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

07 Apr 2024 20:19, I wrote to you:

I've added a couple new settings to my JamNNTPd fork (https://github.com/cnb/jamnntpd/) that I hope will fix some of the
issues with spaces and quotes.

- def_nonbsp (user parameter nonbsp) for replacing UTF-8 non-breaking spaces by regular spaces.

I've improved that feature with this commit:

https://github.com/cnb/jamnntpd/commit/0896df56e754770ef0d9730d7e0260ca896fe54f

- replace Unicode NBSPs only in UTF-8 articles
- replace NBSPs also in ISO-8859-* and Windows-125x articles

Carlos

--- GoldED+/W32-MSVC 1.1.5-b20180707
* Origin: cyberiada (2:341/234.1)

Hello Carlos,

On Wed, 01 May 2024 20:07:14 +0200, you wrote to All:

I've improved that feature with this commit:

Thanks Carlos!

Regards,
Nick

... Take my advice, I don't use it anyway.
--- GoldED+/LNX 1.1.5-b20240309
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On 01.05.2024 23:35, Nicholas Boel wrote:

On Wed, 01 May 2024 20:07:14 +0200, you wrote to All:

 CN>> I've improved that feature with this commit:

Thanks Carlos!

Thanks Carlos! :)

'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

On 02.05.2024 7:35, Nicholas Boel -> Carlos Navarro wrote:

Hello Carlos,

On Wed, 01 May 2024 20:07:14 +0200, you wrote to All:

 CN>> I've improved that feature with this commit:

Thanks Carlos!

Regards,
Nick

... Take my advice, I don't use it anyway.
--- GoldED+/LNX 1.1.5-b20240309
 * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Test.

...
---
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On Sat, 4 May 2024 05:43:00 -0500, Tommi Koivula -> Nicholas Boel wrote:

Test.

...
---
 * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Not sure if you actually saw anything odd, but there was a typo in my commit, pointed out by Carlos, that has since been fixed.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On Sat, 4 May 2024 05:43:00 -0500, Tommi Koivula -> Nicholas Boel wrote:

I've improved that feature with this commit:

Thanks Carlos!

Test.

Testing another typo fix in 2.4.3 commit.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On 04.05.2024 13:41, Nicholas Boel wrote:

On Sat, 4 May 2024 05:43:00 -0500, Tommi Koivula -> Nicholas Boel wrote:

 TK> Test.

 TK> ...
 TK> ---
 TK>  * Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Not sure if you actually saw anything odd, but there was a typo in my
commit, pointed out by Carlos, that has since been fixed.

Yes I did. I applied your pathes to smapinntpd, and then reverted back. Tested your server also.

Then I had no time to test more. ;)

Continuing now..

---
* Origin: smapinntpd/lnx (2:221/1.0)

On 04.05.2024 14:37, Nicholas Boel wrote:

On Sat, 4 May 2024 05:43:00 -0500, Tommi Koivula -> Nicholas Boel wrote:

I've improved that feature with this commit:

Thanks Carlos!

Test.

Testing another typo fix in 2.4.3 commit.

I think I've got it ok now. ;)

'Tommi

---
* Origin: smapinntpd/lnx (2:221/1.0)

On Sat, 4 May 2024 23:28:08 +0300, Tommi Koivula -> Nicholas Boel wrote:

Yes I did. I applied your pathes to smapinntpd, and then reverted back. Tested your server also.

Then I had no time to test more. ;)

Continuing now..

Fixed now. I fixed the typo that was in both forks as pointed out by Carlos, and then found another typo in Smapinntpd only. No more adding patches in a hurry, that's for sure. :)

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On Sat, 4 May 2024 23:48:18 +0300, Tommi Koivula -> Nicholas Boel wrote:

I think I've got it ok now. ;)

That's good. I was worried about you for a second there. ;)

BTW, is "@RFC-User-Agent:" a better choice over "NOTE:" according to some such standards I don't care to read? I've noticed you recently changed this.

By all means, please feel free to share your findings and suggestions.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On 04.05.2024 15:52, Nicholas Boel wrote:

On Sat, 4 May 2024 23:48:18 +0300, Tommi Koivula -> Nicholas Boel wrote:

I think I've got it ok now. ;)

That's good. I was worried about you for a second there. ;)

Sorry. ;D

BTW, is "@RFC-User-Agent:" a better choice over "NOTE:" according to
some such standards I don't care to read? I've noticed you recently
changed this.

I wanted to "log" something from nntp client to kludges. So NOTE was changed to what the client sends.. Just for testing..

X-SMAPI-Control: @RFC-User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:115.0) Gecko/20100101 Thunderbird/115.10
X-SMAPI-Control: @RFC-Content-Type: text/plain; charset=UTF-8; format=flowed X-SMAPI-Control: @RFC-Content-Transfer-Encoding: 8bit

'Tommi

--- FMail-lnx64 2.3.2.3-B20240503
* Origin: nntp://news.fidonet.fi (2:221/6.0)

On Sun, 5 May 2024 00:14:44 +0300, Tommi Koivula -> Nicholas Boel wrote:

BTW, is "@RFC-User-Agent:" a better choice over "NOTE:" according to
some such standards I don't care to read? I've noticed you recently
changed this.

I wanted to "log" something from nntp client to kludges. So NOTE was changed to what the client sends.. Just for testing..

X-SMAPI-Control: @RFC-User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64;
x64; rv:115.0) Gecko/20100101 Thunderbird/115.10
X-SMAPI-Control: @RFC-Content-Type: text/plain; charset=UTF-8; format=flowed
X-SMAPI-Control: @RFC-Content-Transfer-Encoding: 8bit

Is that specific to Thunderbird and/or Sylpheed? I believe slrn and tin it doesn't use or display "RFC". It just sends "User-Agent:", "Content-Type:", and "Content-Transfer-Encoding:".

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On 04.05.2024 20:20, Nicholas Boel wrote:

On Sun, 5 May 2024 00:14:44 +0300, Tommi Koivula -> Nicholas Boel wrote:

BTW, is "@RFC-User-Agent:" a better choice over "NOTE:" according to
some such standards I don't care to read? I've noticed you recently
changed this.

I wanted to "log" something from nntp client to kludges. So NOTE was changed to what the client sends.. Just for testing..

X-SMAPI-Control: @RFC-User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:115.0) Gecko/20100101 Thunderbird/115.10
X-SMAPI-Control: @RFC-Content-Type: text/plain; charset=UTF-8; format=flowed
X-SMAPI-Control: @RFC-Content-Transfer-Encoding: 8bit

Is that specific to Thunderbird and/or Sylpheed? I believe slrn and tin
it doesn't use or display "RFC". It just sends "User-Agent:", "Content-Type:", and "Content-Transfer-Encoding:".

The "RFC-" part of the kludge was added by me.

'Tommi

---
* Origin: jamnntpd/lnx (2:221/1.0)

On Sun, 5 May 2024 01:34:10 +0300, Tommi Koivula -> Nicholas Boel wrote:

Is that specific to Thunderbird and/or Sylpheed? I believe slrn and tin
it doesn't use or display "RFC". It just sends "User-Agent:",
"Content-Type:", and "Content-Transfer-Encoding:".

The "RFC-" part of the kludge was added by me.

I get that. But, did you get that from some technical document that that should be in use?

Or is this something you've just done yourself because FMail adds a RFC-X-NO-ARCHIVE kludge?

From Wikipedia:

"The proper field to prevent a message from being archived is: X-No-Archive: Yes (abbreviated as "XNAY")."

So I imagine what FMail is doing, isn't actually preventing messages from being archived.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On 04.05.2024 13:59, Nicholas Boel wrote:

Is that specific to Thunderbird and/or Sylpheed? I believe slrn
and tin it doesn't use or display "RFC". It just sends
"User-Agent:", "Content-Type:", and
"Content-Transfer-Encoding:".

The "RFC-" part of the kludge was added by me.

I get that. But, did you get that from some technical document that
that should be in use?

Nope.. Just my own thing, something what soupgate does..

Or is this something you've just done yourself because FMail adds a RFC-X-NO-ARCHIVE kludge?

Nothing to do with FMail. Actually I cannot find anything like that in
fmail docs or in the code. Maybe it is the GoldED of Wilfred that is
adding that kludge. ;)

From Wikipedia:

"The proper field to prevent a message from being archived is:
X-No-Archive: Yes (abbreviated as "XNAY")."

So I imagine what FMail is doing, isn't actually preventing messages
from being archived.

In the fidonet, probably not.

'Tommi

--- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:115.0) Gecko/20100101 Thunderbird/115.10.1
* Origin: nntp point at (2:221/1.1)

Hi Tommi,

On 2024-05-05 08:24:13, you wrote to Nicholas Boel:

Or is this something you've just done yourself because FMail adds a
RFC-X-NO-ARCHIVE kludge?

Nothing to do with FMail. Actually I cannot find anything like that in fmail docs or in the code.

It indeed has nothing to do with FMail.

Maybe it is the GoldED of Wilfred that is adding that kludge. ;)

That is true.

From Wikipedia:

"The proper field to prevent a message from being archived is:
X-No-Archive: Yes (abbreviated as "XNAY")."

So I imagine what FMail is doing, isn't actually preventing messages
from being archived.

In the fidonet, probably not.

I have no illusions about that. It's incase my messages are gated to newsgroups in some of the fido areas...


Bye, Wilfred.

--- FMail-lnx64 2.3.2.3-B20240423
* Origin: FMail development HQ (2:280/464)

On Sun, 5 May 2024 13:24:12 +0300, Tommi Koivula -> Nicholas Boel wrote:

I get that. But, did you get that from some technical document that
that should be in use?

Nope.. Just my own thing, something what soupgate does..

Ah, ok.

Or is this something you've just done yourself because FMail adds a
RFC-X-NO-ARCHIVE kludge?

Nothing to do with FMail. Actually I cannot find anything like that in fmail docs or in the code. Maybe it is the GoldED of Wilfred that is adding that kludge. ;)

That's also possible. I just don't understand where the "RFC" prefix came from for some of these headers (even the few already in use in Fidonet). I can't find any reference to that prefix anywhere.


Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

On Sun, 5 May 2024 17:46:52 +0200, Wilfred Van Velzen -> Tommi Koivula wrote:

It indeed has nothing to do with FMail.

Maybe it is the GoldED of Wilfred that is adding that kludge. ;)

That is true.

Thank you for clarification, however *what* was adding that kludge wasn't really the point.

From Wikipedia:

"The proper field to prevent a message from being archived is:
X-No-Archive: Yes (abbreviated as "XNAY")."

So I imagine what FMail is doing, isn't actually preventing messages
from being archived.

I have no illusions about that. It's incase my messages are gated to newsgroups in some of the fido areas...

Right, but the question is (after reading that wiki site, and finding no reference to said prefix), is if the newsgroup software(s) are looking for an "X-NO-ARCHIVE" or an "RFC-X-NO-ARCHIVE" header field. According to the above, adding the "RFC" prefix would cause the search for the proper header field to fail, as would the rest of the ones Tommi has changed. That's why I asked.

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Nicholas Boel wrote:

Right, but the question is (after reading that wiki site, and
finding no reference to said prefix), is if the newsgroup software
(s) are looking for an "X-NO-ARCHIVE" or an "RFC-X-NO-ARCHIVE"
header field. According to the above, adding the "RFC" prefix would
cause the search for the proper header field to fail, as would the
rest of the ones Tommi has changed. That's why I asked.

If some news archive software is searching for "X-NO-ARCHIVE", it might
be happy to find "RFC-X-NO-ARCHIVE". :)

'Tommi

--- FMail-lnx64 2.3.2.3-B20240504
* Origin: jamnntpd/lnx (2:221/6.0)

Nicholas Boel wrote:

That's also possible. I just don't understand where the "RFC"
prefix came from for some of these headers (even the few already in
use in Fidonet). I can't find any reference to that prefix anywhere.

Well, even GoldED has some 'RFC' things in its internet support..

'Tommi

--- -- -
* Origin: nntp point at (2:221/1.1)

Hi Nicholas.

05 May 24 20:20:30, I wrote to Nicholas Boel:

That's also possible. I just don't understand where the "RFC"
prefix came from for some of these headers (even the few already in
use in Fidonet). I can't find any reference to that prefix anywhere.

Well, even GoldED has some 'RFC' things in its internet support..

However, even if I set "AREAISNEWS JAMNNTPD", GoldED will not use the
"RFC-" prefix.

Ok, Offtopic here. ;)

'Tommi

---
* Origin: Point One (2:221/1.1)

On Mon, 6 May 2024 01:14:18 +0300, Tommi Koivula -> Nicholas Boel wrote:

If some news archive software is searching for "X-NO-ARCHIVE", it might
be happy to find "RFC-X-NO-ARCHIVE". :)

Also very possible. Then again, it may just skip it because it has no idea what it's supposed to mean. :)

Regards,
Nick

... Take my advice, I don't use it anyway.
--- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderb
* Origin: _thePharcyde distribution system (Wisconsin) (1:154/10)

Hi Nicholas,

On 2024-05-05 07:10:28, you wrote to me:

Right, but the question is (after reading that wiki site, and finding
no reference to said prefix), is if the newsgroup software(s) are
looking for an "X-NO-ARCHIVE" or an "RFC-X-NO-ARCHIVE" header field. According to the above, adding the "RFC" prefix would cause the search
for the proper header field to fail, as would the rest of the ones
Tommi has changed. That's why I asked.

I don't remember the details from when I started using it. It was recommended to add it this way...

Bye, Wilfred.

--- FMail-lnx64 2.3.2.3-B20240423
* Origin: FMail development HQ (2:280/464)