Re: [Pan-users] interface bug (or not?)

[Duncan]

Jim Henderson posted on Sun, 10 Mar 2024 00:20:07 -0000 (UTC) as
excerpted:

> On Sat, 9 Mar 2024 02:41:42 -0000 (UTC), Duncan wrote:
> 
>> AFAIK it's not a size threshold per se, but rather, it happens with a
>> message split into several parts (sub-messages, each sent separately,
>> not multiple parts as in a text part, and html part, maybe other parts,
>> all sent in different sections of the same message, the other meaning
>> of multi-part) for sending.  Because this tends to happen with larger
>> messages it does somewhat correspond to size, but the same message sent
>> with a single-part size set low enough to trigger pre-send splitting
>> and sending of those separate parts as different messages will trigger
>> this when pan encounters it, while it won't if the single-part size was
>> set high enough that it was sent as a single un-split message.
> 
> I thought this was the case, but it doesn't seem to be.

Sometimes a qualifier like AFAIK is there for a reason. =:^)

I (think I) found the actual code. =:^)  See below but....

Note that while as a gentooing sysadmin running some packages (including 
pan and much of kde-frameworks/plasma/gear) built and updated from live-
git, I've become accustomed to reading git logs and occasionally doing 
patches based off them, I'm not a dev and don't have the skills to go much 
beyond tweaking patches I come across, thus the "think I" qualifier...  
So: read the below code discussion with that big caveat!

> I was mistaken in saying that I access that povray group on gmane - it's
> actually its own DNews server.  In the group povray.binaries.images, you
> can see the message at the root of the thread "Reservations" (message ID
> 148096) is a single message with a very long binary attachment.
> 
> There's no "part 2" - the message itself is 66,329 lines long, and (if
> you tee the output from nc to a file), you can see that the boundary at
> the top and at the bottom makes a complete file (you have to use
> unix2dos to convert crlf to lf only before using base64 to decode it).
> 
> So while this may happen with multipart posts, it also does happen with
> single posts that contain a large encoded binary as well.

OK, using a keyword (is_smallish) from an old patch I had I grepped (well, 
mcedit-searched) the code and found this in header-pane.cc (code wraps in 
a couple places but line numbers are included and make it obvious where):


1252
1253 namespace
1254 {
1255   bool has_image_type_in_subject (const Article& a)
1256   {
1257     const StringView s (a.subject.to_view());
1258     return s.strstr(".jpg") || s.strstr(".JPG") ||
1259            s.strstr(".gif") || s.strstr(".GIF") ||
1260            s.strstr(".jpeg") || s.strstr(".JPEG") ||
1261            s.strstr(".png") || s.strstr(".PNG");
1262   }
1263
1264   gboolean on_row_activated_idle (gpointer pane_g)
1265   {
1266     HeaderPane * pane (static_cast<HeaderPane*>(pane_g));
1267     const Article * a (pane->get_first_selected_article());
1268     if (a) {
1269       const size_t lines = a->get_line_count();
1270       const bool is_smallish = lines  <= 5000;
1271       const bool is_mediumish = lines <= 20000;
1272       const bool image_subject = has_image_type_in_subject (*a);
1273       const bool is_pictures_newsgroup = pane-
>get_group().to_view().strstr("pictures")!=nullptr;
1274       if (is_smallish || image_subject)
1275         pane->_action_manager.activate_action ("read-selected-
article");
1276       else if (is_mediumish && is_pictures_newsgroup)
1277         pane->_action_manager.activate_action ("read-selected-
article");
1278       else
1279         pane->_action_manager.activate_action ("save-articles");
1280     }
1281     return false;
1282   }
1283 }
1284

In closer-to-plain-English pseudocode:

First we have a broken-out boolean has_image_type_in_subject (), which 
searches for image-extension strings ( jpg/gif/jpeg/png) in the subject 
line, returning true/false accordingly.

Then we have the code that's actually interesting to us, gboolean 
on_row_activated_idle, which conditionally activates EITHER read-selected-
article OR save-articles.

We're interested in those conditions. (I'm working with/around pan's 
wrapping code here, while trying to avoid triggering its quote-
recognition, thus the *** style logic indention.):

* If there's a valid first-selected-article and it:

**      Is "smallish"
**      (defined as having 5000 lines or less)
**      OR
**      has a subject line indicating an image
**      (tested using the broken-out boolean test above)

***             Auto-activate read-selected-article

**      Is "mediumish"
**      (defined as having 20,000 lines or less)
**      AND
**      is a pictures newsgroup
**      (tests for "pictures" in the newsgroup name)

***             Auto-activate read-selected-article

**      Otherwise (still assuming a valid first-selected-article):

***             Auto-activate save-articles

* Otherwise (no valid first-selected-article):

**      Just return false


With that in mind I can now explain the old is_smallish patch I mentioned 
above.  It simply doubles that 5000 lines to 10,000, and I have it placed 
in a directory such that the usual gentoo ebuild/emerge mechanism auto-
applies it every time I update pan.  (The discussion-punt of the last 
paragraph below applies here too...)

Meanwhile (#1), the OP's claim was that while visiting...

gmane.org.unix-heritage.general

... he came across an article that didn't "auto-read", instead opening the 
save-article dialog.  He considered that a bug.

* We know that group name doesn't include "pictures" so the "mediumish" 
test fails regardless of the number of lines.

* We do NOT know the what the subject line was or how many lines the post 
actually was, but from the described behavior and the logic above we can 
ASSUME the post was BOTH over 5000 lines AND did not trigger the image-
type-in-subject test.

* So it fell through to the valid-selected-article:true OTHERWISE 
condition and auto-activated save-articles.

Meanwhile (#2), Jim confirmed the behavior with a different post, in...

povray.binaries.images

* No "pictures" in the name so mediumish wouldn't trigger regardless of 
size.

* Post 66k+ lines so "smallish" doesn't trigger on size.

* Message subject "Reservations" so the image-extension test doesn't 
trigger.

Here we have all the information to follow the logic through the code 
above, and it triggers the save-article fall-through.

Meanwhile (#3), I believe the behavior I was describing for multi-part, 
where it doesn't auto-trigger EITHER the auto-save-dialog OR the auto-
read, must be on that last fall-through condition, no valid article, 
apparently the multi-part, so it doesn't auto-read OR auto-save-dialog, 
just returns false.


What remains is to discuss whether this behavior can be properly described 
as a bug or not, and whether to tweak (if it's not a bug but maybe a test 
tweak is justified) or change (if it is a bug) the logic and behavior 
above, but this behavior analysis post is long enough so that can be a 
followup.

-- 
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