On 9/9/23 17:36, Ben Bacarisse wrote:
> But I am not advocating you use it; after all, I don't. I just didn't
> like the implication that the documentation was not truthful. You can
> read offline. It doesn't say you can do so effortlessly or even
> conveniently!
>

Yea, that's fair enough.

--
--
user <candycane> is generated from /dev/urandom

[ Dropped comp.lang.c , added news.software.readers ]

On Sat, 9 Sep 2023 21:28:11 -0000 (UTC)
Rich <rich@example.invalid> wrote:
> In comp.misc candycanearter07 <no@thanks.net> wrote:
> > On 9/9/23 03:57, Sn!pe wrote:
> >> This is not to say that T'Bird is no good as a Newsreader, but there are
> >> better ones.
> >
> > It's hard to find one for Linux that I can find in the aur and also has
> > offline reading mode. Pan doesn't have any option to download all unread
> > messages from what I know.
>
> From the Linux perspective, that is out of scope for a newsreader.
> Offline read/write mode is done with, as one option,
> https://en.wikipedia.org/wiki/Leafnode. Then you still use whatever
> newsreader you like, but can do so offline as well.

I think it is perfectly reasonable for a newsreader to have both a
"batch mode" and an interactive mode. For example one might want to go for
a trip and still set their newsreader to download all new messages in their
favorite groups once per day.

slrn claims to offer such capabilities but I don't use it so I can't speak
about details. It also seems to be easy to compile from source (very few
dependencies) which is a plus in my book because one can make modifications.
But slrn also supports an extension language called S-lang so I'm
guessing you can customise it a lot. Details are under http://slrn.info/ .

It should also be easy to write a Python script or Perl script to download
all new messages from some groups. But one must still use a newsreader which
supports the functionality to read messages from the local filesystem as
opposed to connect to a server and also the messages must be saved in a
format the newsreader can understand.

--
vlaho.ninja/prog

Spiros Bousbouras wrote:

> [ Dropped comp.lang.c , added news.software.readers ]
>
> On Sat, 9 Sep 2023 21:28:11 -0000 (UTC)
> Rich <rich@example.invalid> wrote:
>> In comp.misc candycanearter07 <no@thanks.net> wrote:
>> > On 9/9/23 03:57, Sn!pe wrote:
>> >> This is not to say that T'Bird is no good as a Newsreader, but there are
>> >> better ones.
>> >
>> > It's hard to find one for Linux that I can find in the aur and also has
>> > offline reading mode. Pan doesn't have any option to download all unread
>> > messages from what I know.
>>
>> From the Linux perspective, that is out of scope for a newsreader.
>> Offline read/write mode is done with, as one option,
>> https://en.wikipedia.org/wiki/Leafnode. Then you still use whatever
>> newsreader you like, but can do so offline as well.
>
> I think it is perfectly reasonable for a newsreader to have both a
> "batch mode" and an interactive mode. For example one might want to go for
> a trip and still set their newsreader to download all new messages in their
> favorite groups once per day.
>
> slrn claims to offer such capabilities but I don't use it so I can't speak
> about details. It also seems to be easy to compile from source (very few
> dependencies) which is a plus in my book because one can make modifications.
> But slrn also supports an extension language called S-lang so I'm
> guessing you can customise it a lot. Details are under http://slrn.info/ .
>
> It should also be easy to write a Python script or Perl script to download
> all new messages from some groups. But one must still use a newsreader which
> supports the functionality to read messages from the local filesystem as
> opposed to connect to a server and also the messages must be saved in a
> format the newsreader can understand.

pan and sylpheed grant offline reading from what i recall. slrn has got
slrnpull, which is great for offline reading/posting (used it with gnus
in place of its native agent in the ol' days). leafnode2 is a good
alternative, not overshooting, as it's light and maintenance free once
porperly set up. i've heard of noffle, never tried tho

On 9/10/23 03:24, Spiros Bousbouras wrote:

> slrn claims to offer such capabilities but I don't use it so I can't speak
> about details. It also seems to be easy to compile from source (very few
> dependencies) which is a plus in my book because one can make modifications.
> But slrn also supports an extension language called S-lang so I'm
> guessing you can customise it a lot. Details are under http://slrn.info/ .

slrn errors when I tried to install it.
bytecode stream in file ‘/usr/lib/uudeview/fptools.o’ generated with LTO
version 12.0 instead of the expected 13.0

--
--
user <candycane> is generated from /dev/urandom

On 2023-09-10, candycanearter07 <no@thanks.net> wrote:
> On 9/10/23 03:24, Spiros Bousbouras wrote:
>
>> slrn claims to offer such capabilities but I don't use it so I can't speak
>> about details. It also seems to be easy to compile from source (very few
>> dependencies) which is a plus in my book because one can make modifications.
>> But slrn also supports an extension language called S-lang so I'm
>> guessing you can customise it a lot. Details are under http://slrn.info/ .
>
> slrn errors when I tried to install it.
> bytecode stream in file ‘/usr/lib/uudeview/fptools.o’ generated with LTO
> version 12.0 instead of the expected 13.0

I downloaded the source and compiled it myself. For Termux (Linux under
Android; minor edits required but if it works there...)

GitHub - jedsoft/slrn: A multi-platform Usenet client
https://github.com/jedsoft/slrn

On Sat, 9 Sep 2023 22:33:45 +0100, Sn!pe wrote:

> candycanearter07 <no@thanks.net> wrote:
<snips>
>> I'm on Linux, but thanks. I'll check out slrn.
>>
> Pan is often the GUI choice for Linux users.

As windows user that has used XNews, slrn, Gravity (by GRC), and Pan for
Windows, I'll add that all of these clients are excellent, but each has
their own weaknesses. I was affected by the bugs for Pan for Windows that
result in the various panes being turned black and becoming unusable.

XNews would be my perfect newsreader, but it's so dated now, and can't
handle more modern usages well, such as double-byte character sets
(unicode, utf8). Also, no modern tls. (yes, I'm aware of stunnel
approaches, but I'm also lazy)

slrn I think of more as an "online" reader. It's ability to hold onto
downloaded bodies and show them intelligently in a "show full threads with
new messages" sort of way is... doable but awkward. I acutally kind of
like that it's a console-only client, but for my normal usage it's just
slightly clunky. It's also 'almost' perfect, and I still use it regularly
when I get bored and read usenet over ssh from work (or other places I
probably shouldn't). Also no modern tls.

Gravity by GRC has been updated *just enough* to be viable, but it departs
from the truly excellent scorefile approach shared by xnews/slrn/pan. It's
perfectly usable, but its overall philosophy is really "one reader, one
news server". It lacks the same *easy* mutlti-server/identity flexibility
of the other clients.

Each of these clients have their own "approach". I like all of them, and
have used each extensively.

Ultimately, recently, I have landed on Pan for Linux, but using WSL2
(windows subsystem for Linux) under Windows 11, which lets me use Pan for
linux on a windows machine. It does not suffer from the same bugs that the
2019 build of Pan for Windows does. And I am happiest with this, for now!

Pan is an excellent gui, supports modern TLS, handles multi-identity,
multi-server, and handles unicode just fine. It also tries to add a GUI in
front of the score file, but I prefer to edit that manually, and it
supports it fantastically. I'd move to Pan for Windows again if an updated
build fixed the bugs for me, to avoid the cost of virtualization, but
honestly WSL2 is good enough that I'm ok with the tradeoffs for now
(haven't yet figured out how to make links clickable... gnome link
handlers aren't integerated with my windows browser, but I don't care that
much, the clipboard is seamless so I can just copy/paste).

I wish more effort was put into maintaining modern windows *text based*
newsreaders these days. I'm not a binaries fellow. But for now this is
working for me.

Lafe

ps - sorry, what was meant to be a quick follow up turned into a minor
essay.

["Followup-To:" header set to comp.misc.]
On 2023-09-10, candycanearter07 wrote:
> On 9/10/23 03:24, Spiros Bousbouras wrote:
>
>> slrn claims to offer such capabilities but I don't use it so I can't
>> speak about details [...]
> slrn errors when I tried to install it.
> bytecode stream in file ‘/usr/lib/uudeview/fptools.o’ generated with LTO
> version 12.0 instead of the expected 13.0

Are you using the version in your distro's repository, or getting it
elsewhere?

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 9/9/23 16:28, Rich wrote:
> From the Linux perspective, that is out of scope for a newsreader.

I don't know if I agree with that statement. While it's not something
necessary for a good newsreader, it definitely seems like an obvious
nice-to-have feature, allowing a user to configure offline reading from
within the actual app they're using, rather than reading manuals for
some other piece of software.

--
~rdh

Spiros Bousbouras <spibou@gmail.com> writes:

[...]

> Finally (for comp.lang.c only) , I find even more annoying than the spam
> the fact that people don't choose an appropriate Subject: for their posts.
> Naming a thread "bart again (UCX64)" is a poor choice anyway but it
> contains a long subthread on whether the closing brace of a function is
> reachable and whether a compiler should give a warning. It would certainly
> help if posts relevant to this reflected it in the Subject: .

[...]

One difficulty there is that a good subject requires a summary of the
content, a hard problem that schools have been failing to solve.
Notice, too, that lay people write the subject first and the message,
second, which is roughly the same as writing out the number first and
doing the arithmetic later.

So we can sort of blame that partly on the user interfaces. Somehow,
the subject line should come as a last step. That might be one of the
reasons lay people love the new proprietary software for conversations
--- they don't ask them to solve hard problems. On the contrary: they
force them not to solve them. (You don't have much to say? No problem:
we won't let you write more than n characters anyway.)

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> candycanearter07 <no@thanks.net> writes:
>
>> On 9/9/23 03:57, Sn!pe wrote:
>>> This is not to say that T'Bird is no good as a Newsreader, but there are
>>> better ones.
>>
>> It's hard to find one for Linux that I can find in the aur and also has
>> offline reading mode. Pan doesn't have any option to download all unread
>> messages from what I know.
>
> Pan claims to support offline reading. And Gnus certainly does. The
> trouble with Gnus, though, is that if you are not already steeped in
> Emacs, it might hard to get to grips with.

True. Even if you're stepped in EMACS, Gnus is still hard to get to
grips with. But surely the greatest feature of Gnus is precisely that
it runs in the GNU EMACS.

But speaking of offline reading, one feature of Gnus that I really like
is that when I open the first article on a thread, it downloads some
subsequent articles, so when I ask for the next it is already there for
me.

issdr <p_u_n_k_i_n_d@yahoo.it> writes:

[...]

> pan and sylpheed grant offline reading from what i recall. slrn has got
> slrnpull, which is great for offline reading/posting (used it with gnus
> in place of its native agent in the ol' days). leafnode2 is a good
> alternative, not overshooting, as it's light and maintenance free once
> porperly set up. i've heard of noffle, never tried tho

I tried noffle. Noffle is as great as leafnode, but I moved away from
noffle because messages were stored in a GDBM while leafnode stores them
on a directory.

On Sun, 03 Dec 2023 13:01:28 -0300, Julieta Shem wrote:

> So we can sort of blame that partly on the user interfaces. Somehow,
> the subject line should come as a last step. That might be one of the
> reasons lay people love the new proprietary software for conversations
> --- they don't ask them to solve hard problems. On the contrary: they
> force them not to solve them. (You don't have much to say? No problem:
> we won't let you write more than n characters anyway.)

Even worse, these modern interfaces often /force/ people to post,
inundating the medium with trivial chatter. ("You don't have anything to
say? Too bad; you need to post /something/ in order to keep your account
open.")

--
Lew Pitcher
"In Skills We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> On Sun, 03 Dec 2023 13:01:28 -0300, Julieta Shem wrote:
>
>> So we can sort of blame that partly on the user interfaces. Somehow,
>> the subject line should come as a last step. That might be one of the
>> reasons lay people love the new proprietary software for conversations
>> --- they don't ask them to solve hard problems. On the contrary: they
>> force them not to solve them. (You don't have much to say? No problem:
>> we won't let you write more than n characters anyway.)
>
> Even worse, these modern interfaces often /force/ people to post,
> inundating the medium with trivial chatter. ("You don't have anything to
> say? Too bad; you need to post /something/ in order to keep your account
> open.")

That's wild. (I had no idea.) Some things such as education and
communities can never be guided by commerce. It has to come from within
the community itself. If it ever becomes commercial, then we should
backtrack.

On 03/12/2023 16:01, Julieta Shem wrote:
> One difficulty there is that a good subject requires a summary of the
> content, a hard problem that schools have been failing to solve.
> Notice, too, that lay people write the subject first and the message,
> second, which is roughly the same as writing out the number first and
> doing the arithmetic later.
>
> So we can sort of blame that partly on the user interfaces. Somehow,
> the subject line should come as a last step. That might be one of the
> reasons lay people love the new proprietary software for conversations
> --- they don't ask them to solve hard problems. On the contrary: they
> force them not to solve them. (You don't have much to say? No problem:
> we won't let you write more than n characters anyway.)

The problem there is that when you are reading the message you want the
title (summary) first.

It's quite valid to say you should write it later - but that would
result in a different layout for reading and writing, which would be
confusing.

For me having the title first works most of the time. It's a one line
summary of what I want to talk about. I then expand on it in the body.
Occasionally I go back and change the title - but not often.

Andy

On 12/3/23 10:39, Lew Pitcher wrote:
> On Sun, 03 Dec 2023 13:01:28 -0300, Julieta Shem wrote:
>
>> So we can sort of blame that partly on the user interfaces. Somehow,
>> the subject line should come as a last step. That might be one of the
>> reasons lay people love the new proprietary software for conversations
>> --- they don't ask them to solve hard problems. On the contrary: they
>> force them not to solve them. (You don't have much to say? No problem:
>> we won't let you write more than n characters anyway.)
>
> Even worse, these modern interfaces often /force/ people to post,
> inundating the medium with trivial chatter. ("You don't have anything to
> say? Too bad; you need to post /something/ in order to keep your account
> open.")
>
>

Even Google Drive is doing that now. (Though, to be fair, storage space
is expensive)
--
user <candycane> is generated from /dev/urandom

Vir Campestris <vir.campestris@invalid.invalid> writes:

> On 03/12/2023 16:01, Julieta Shem wrote:
>> One difficulty there is that a good subject requires a summary of the
>> content, a hard problem that schools have been failing to solve.
>> Notice, too, that lay people write the subject first and the message,
>> second, which is roughly the same as writing out the number first and
>> doing the arithmetic later.
>>
>> So we can sort of blame that partly on the user interfaces. Somehow,
>> the subject line should come as a last step. That might be one of
>> the reasons lay people love the new proprietary software for
>> conversations --- they don't ask them to solve hard problems. On the
>> contrary: they force them not to solve them. (You don't have much to
>> say? No problem: we won't let you write more than n characters
>> anyway.)
>
> The problem there is that when you are reading the message you want
> the title (summary) first.

Can we untie the way it is displayed from the way it is written?

> It's quite valid to say you should write it later - but that would
> result in a different layout for reading and writing, which would be
> confusing.

Why? It seems more confusing to have to write it first --- ``omg, I
need a subject, what do I put in there?'' If I can't decide, that's the
very definition of confusion.

> For me having the title first works most of the time. It's a one line
> summary of what I want to talk about. I then expand on it in the
> body. Occasionally I go back and change the title - but not often.

So true. More often than not now, I write it last. I've probably
rewritten it so many times now that I perhaps learned that it's less
work to write it last.

On 12/3/23 10:39, Lew Pitcher wrote:
>
> Even worse, these modern interfaces often /force/ people to post,
> inundating the medium with trivial chatter. ("You don't have anything to
> say? Too bad; you need to post /something/ in order to keep your account
> open.")

You are not the customer. You are the product. Forcing people to post
to keep their account open means more traffic, and traffic is money.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2023-12-04 20:46, Scott Dorsey wrote:
> On 12/3/23 10:39, Lew Pitcher wrote:
>>
>> Even worse, these modern interfaces often /force/ people to post,
>> inundating the medium with trivial chatter. ("You don't have anything to
>> say? Too bad; you need to post /something/ in order to keep your account
>> open.")
>
> You are not the customer. You are the product. Forcing people to post
> to keep their account open means more traffic, and traffic is money.
> --scott

And that's the truth.

Julieta Shem <jshem@yaxenu.org> writes:

> On 2023-12-04 20:46, Scott Dorsey wrote:
>> On 12/3/23 10:39, Lew Pitcher wrote:
>>>
>>> Even worse, these modern interfaces often /force/ people to post,
>>> inundating the medium with trivial chatter. ("You don't have anything to
>>> say? Too bad; you need to post /something/ in order to keep your account
>>> open.")
>> You are not the customer. You are the product. Forcing people to
>> post
>> to keep their account open means more traffic, and traffic is money.
>> --scott
>
> And that's the truth.

Oh, I'm sorry for messing up your quote. That was ThunderBird's fault
or my fault for not setting it up properly. (I have been trying it
out.)

Julieta Shem <jshem@yaxenu.org> writes:
>Julieta Shem <jshem@yaxenu.org> writes:
>
>> On 2023-12-04 20:46, Scott Dorsey wrote:
>>> On 12/3/23 10:39, Lew Pitcher wrote:
>>>>
>>>> Even worse, these modern interfaces often /force/ people to post,
>>>> inundating the medium with trivial chatter. ("You don't have anything to
>>>> say? Too bad; you need to post /something/ in order to keep your account
>>>> open.")
>>> You are not the customer. You are the product. Forcing people to
>>> post
>>> to keep their account open means more traffic, and traffic is money.
>>> --scott
>>
>> And that's the truth.
>
>Oh, I'm sorry for messing up your quote. That was ThunderBird's fault
>or my fault for not setting it up properly. (I have been trying it
>out.)

A properly written signature block will automatically be discarded
on replies by most well-written NNTP clients.

On 12/3/23 15:29, Vir Campestris wrote:
> The problem there is that when you are reading the message you want
> the title (summary) first.

That's a UI -> UX problem.

On 12/4/23 17:34, Julieta Shem wrote:
> Can we untie the way it is displayed from the way it is written?

Yes.

The UI can be changed so that the UX is improved.

Thunderbird will prompt if the subject is blank and ask if you want to
change it before sending.

--
Grant. . . .

Grant Taylor <gtaylor@tnetconsulting.net> writes:

> On 12/3/23 15:29, Vir Campestris wrote:
>> The problem there is that when you are reading the message you want
>> the title (summary) first.
>
> That's a UI -> UX problem.
>
> On 12/4/23 17:34, Julieta Shem wrote:
>> Can we untie the way it is displayed from the way it is written?
>
> Yes.
>
> The UI can be changed so that the UX is improved.

Let's dig further. How should a mail or a USENET client display a form
so that the user fills out the subject only after the whole message is
written?

The most obvious approach, I think, is to put the field at the bottom of
the message. We can expect users writing their message and forgetting
about the subject, but then the send button after pressed would focus
the subject field. That'll annoy users.

Many people couldn't care less, of course. Many people must think that
subjects are a totally useless thing. For these people, perhaps the
client could write something else that would be minimally useful for us.
I don't what would be minimally useful.

> Thunderbird will prompt if the subject is blank and ask if you want to
> change it before sending.

In this case T'Bird misses the heart of the problem we're discussing
here. We're not discussing how to remember to write a subject, but to
only write it after the whole post is written, when it's much easier to
describe it in a few words. (Of course, it's nice to be remembered
about an empty subject.)

Julieta Shem <jshem@yaxenu.org> writes:
>Grant Taylor <gtaylor@tnetconsulting.net> writes:
>
>> On 12/3/23 15:29, Vir Campestris wrote:
>>> The problem there is that when you are reading the message you want
>>> the title (summary) first.
>>
>> That's a UI -> UX problem.
>>
>> On 12/4/23 17:34, Julieta Shem wrote:
>>> Can we untie the way it is displayed from the way it is written?
>>
>> Yes.
>>
>> The UI can be changed so that the UX is improved.
>
>Let's dig further. How should a mail or a USENET client display a form
>so that the user fills out the subject only after the whole message is
>written?

xrn does it perfectly. Opens a new composition window with the
headers filled in and the cursor positioned after the ':' in
the Subject: header.

On 12/5/23 15:22, Julieta Shem wrote:
> Let's dig further. How should a mail or a USENET client display a form
> so that the user fills out the subject only after the whole message is
> written?

I'm sure there are ways.

I would not choose to use such a client.

> The most obvious approach, I think, is to put the field at the bottom of
> the message.

I suspect that's going to cause other problems in and of itself. But
you do you.

I'd be more inclined to have the subject field at both the top and
bottom if the top wasn't sufficient for some reason.

> We can expect users ...
Nope. No we can't.

> Many people couldn't care less, of course. Many people must think that
> subjects are a totally useless thing.

Then there are the opposite that write the entire message in the subject
and nothing in the body.

> For these people, perhaps the
> client could write something else that would be minimally useful for us.
> I don't what would be minimally useful.

Or we could gently use societal push back and ask people to put a
subject in place.

> In this case T'Bird misses the heart of the problem we're discussing
> here. We're not discussing how to remember to write a subject, but to
> only write it after the whole post is written, when it's much easier to
> describe it in a few words. (Of course, it's nice to be remembered
> about an empty subject.)

If the subject is blank and you hit send, Thunderbird asks you for a
subject. -- That sure seem to me like the subject being written after
the rest of the message.

--
Grant. . . .

["Followup-To:" header set to comp.misc.]
On 2023-12-05, Julieta Shem wrote:
> Grant Taylor <gtaylor@tnetconsulting.net> writes:
>
>> On 12/3/23 15:29, Vir Campestris wrote:
>>> The problem there is that when you are reading the message you want
>>> the title (summary) first.
>>
>> That's a UI -> UX problem.
>>
>> On 12/4/23 17:34, Julieta Shem wrote:
>>> Can we untie the way it is displayed from the way it is written?
>>
>> Yes.
>>
>> The UI can be changed so that the UX is improved.
>
> Let's dig further. How should a mail or a USENET client display a form
> so that the user fills out the subject only after the whole message is
> written?

Perhaps the "poor UX" is simply a product of a person not composing
their thoughts enough beforehand when posting something "new"?

Can't speak for anyone else, but I do try to at least compose my
thoughts a little bit before writing up a "new topic" for discussion.

> [...]
> Many people couldn't care less, of course. Many people must think that
> subjects are a totally useless thing.

They're probably the type who also top-post :P

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860