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
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-users
