pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] How best to view HTML in body Pane.


From: Duncan
Subject: Re: [Pan-users] How best to view HTML in body Pane.
Date: Sat, 13 Jun 2015 08:19:48 +0000 (UTC)
User-agent: Pan/0.140 (Chocolate Salty Balls; GIT af87825)

AnthonyL posted on Sat, 13 Jun 2015 01:43:33 +0000 as excerpted:

>> Tho there has been a bit of discussion about the possibility of doing
>> something like the claws-mail HTML-strip mode, which simply strips all
>> the html tags entirely (with the exception, I think, of anchor tags,
>> which it converts to standard non-HTML URLs).
> 
> This is the feature I was looking for, specifically for reading the
> gwene newsgroups which are all HTML formatted RSS feeds posted on
> USENET. That way I could follow a few of my favorite feeds in PAN.
> However, the HTML content is unreadable as it is now. I'll give
> claws-mail HTML-strip mode a look, although I'll be sticking with PAN as
> my preferred newsreader.

If you'd have mentioned gwene as the usage earlier...


I was in that very position myself fourish years ago, along about kde 
4.6/4.7.  Cutting my rather longer first-draft story short, when kmail 
akonadized and broke, I switched to claws-mail for mail, and have been 
very happy with it since. =:^)  But that left kde's akregator, my feed 
handler at the time, as the only thing pulling in a whole host of kdepim 
dependencies and blocking my toggle off of kde semantic-desktop at 
compile time (gentoo), which having on was in turn pulling in its own 
crapload of deps... on a build-from-sources distro which meant building 
all those otherwise unneeded and unused deps as well!  So I decided I 
needed off of akregator as well.

My first idea was gwene for feeds as newsgroups, using pan, since I was 
already using pan for gmane mailing-lists as newsgroups.  I very quickly 
found, as you did, that pan wasn't going to work for that, since the gwene 
feeds as newsgroups posts remained HTML. =:^(

After some research into other available alternatives, I decided claws-
mail for feeds, either using its news capacity for gwene, or using its 
RSSyl feeds-plugin.  By that time I was already familiar with claws-mail 
as I was using it for mail, and had experience with the effectiveness of 
its HTML-stripping mode, which to be honest, *REALLY* pleasantly 
surprised me, as I hadn't really expected it to work as well as it turned 
out it did.  To the doubters out there, you really do need to see it at 
work to know how well it works.  It does a /far/ more effective job than 
I had thought would be possible.

OK, so claws-mail for feeds it was going to be, but I still had two 
problems to solve.  First, I rather liked having separate feeds and email 
(and news), and wanted to keep them that way, but starting up a second 
claws-mail instance wasn't working -- I'd get the first one, the mail 
instance, popping up instead, even when I had them configured 
separately.  I could run one OR the other but not both at once.  Second, 
for the feeds instance I had to decide between using claws-mail in news 
mode with gwene, or using its RSSyl plugin and subscribing to feeds 
myself.

The first issue, being able to run two separate claws-mail instances at 
once, turned out to be a matter of setting a couple environmental vars.  
It uses $HOME to determine where its config can be found, and it uses 
$TMPDIR as the location for a Unix socket used for control purposes.  
When calling claws-mail at the commandline with various parameters, say 
to fetch mail, it will check that control socket to see if there's an 
existing instance running, and will tell it to do whatever if it is 
running, instead of starting a new instance to do it.  That keeps 
multiple instances from trying to access the same files at the same time, 
but doesn't help when you /want/ to run two entirely separate instances, 
as I was trying to do.  So I setup a wrapper script for the feeds 
instance which pointed both $HOME and $TMPDIR at different locations than 
normal (and also unset the $SESSION_MANAGER var, I do this in both the 
mail wrapper and the feeds wrapper, but I forgot why), and then could run 
two separate claws-mail instances without them interfering with each 
other. =:^)

The second issue, deciding whether I was going to use claws-mail news 
mode and gwene, or claws-mail with the RSSyl plugin and direct feed 
subscriptions, was more of a personal preferences thing.  The 
presentation in claws-mail ends up being very similar, but as expected, 
there are some technical differences.

I ended up going with RSSyl and direct feed subscriptions.  That way, I'm 
not dependent on gwene for my feeds.  In general gwene works, but it has 
problems with the way some multi-feed sites work, and can sometimes only 
only subscribe to one of them, as it thinks it's the same feed being 
repeatedly subscribed.  Additionally, there's the hassle of getting gwene 
signed up for the feed, if it's not already getting it.  That's probably 
less of an issue now, as gwene has been around quite a bit longer, now, 
and thus has more feeds already signed up, but when I tried it, gwene 
itself was rather new and was still very actively building out its feed 
collection as people signed them up.

When a feed changes URL, it's a whole lot easier to change it yourself 
for your own direct feed, than it is to post a request that the gwene 
admins change it.

And finally, I guess it's because I'm used to pan's multi-thread handling 
for news, but I wasn't particularly impressed with claws-mail's news 
handling.  Claws-mail is generally single-threaded, fetching one thing at 
a time, and if a fetch errs out for some reason and throws an error 
dialog, the GUI can become unresponsive until the error dialog is found 
(possibly on some other desktop or under a bunch of other windows) and 
clicked.  While it's more or less the same thing with mail and with the 
RSSyl plugin, it doesn't seem to bother me so much there.   Like I said, 
I think it's because I'm used to pan's multi-threading news fetches, etc, 
making me much more sensitive to that in a news context than in a mail or 
feeds context.  Anyway, I didn't much like claws-mail's news handling for 
feeds via gwene, even tho unlike pan, it DID actually work on the reading 
side due to the HTML stripping mode.

OTOH, there's definitely more of a tracking/privacy issue with feeds you 
sign up for directly, vs. "common" feeds via gwene.  Thru gwene, gwene 
knows the feeds and posts you're fetching but doesn't know what you're 
reading or clicking thru.  If you click on an article in the feed to load 
it on the website, any tracking will attribute to the gwene subscription, 
not to a direct personal subscription.  With a direct subscription, 
particularly for those feeds handled by (I think) google's feedburner, 
they can and almost certainly do track click-thrus, altho they won't know 
what articles you read in claws-mail itself.  In particular, there's one 
rather politically oriented feed that's handled by feedburner, that I'm 
acutely aware of and not particularly comfortable with the tracking on, 
but oh, well.


That pretty much covers claws-mail for feeds.  But due to that 
experience, I greatly appreciate claws-mail's HTML stripping feature now, 
and it rather changed my mind on pan getting such a feature.  I still 
don't believe HTML belongs in news, but given that it's going to be there 
in some cases, it would indeed be nice to have a working HTML stripper 
even /close/ to that of claws-mail, which as I said, /really/ surprised 
me at its effectiveness.  If I were a coder, I'd certainly be looking 
into the techniques the claws-mail HTML stripper uses and either trying 
to port the code, or at least port the techniques, into a patch adding 
the same HTML-stripping capacities (making them optional, of course) for 
pan.  But not being a coder...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




reply via email to

[Prev in Thread] Current Thread [Next in Thread]