Duncan posted on Wed, 13 Mar 2024 05:56:53 -0000 (UTC) as excerpted: > 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: > > * 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 > > 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 (#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. OK, bug or not? So the described behavior does have a reason and I'd argue is not a bug -- people arguably do not *want* pan to just start downloading arbitrarily large attachments, *especially* in what they may reasonably expect to be text-only groups, or if someone decides to post say a multi-gig DVD/movie binary to what are supposed to be (relatively small) still-image groups. That code is there to prevent that. Tho I would argue that expectations have changed over time (connections are faster, analog-modem dialup speeds are surely the exception these days, and both message and storage size assumptions are accordingly larger) and that it's arguably time to consider tweaking the condition specifics: I already mentioned that I locally patch the "smallish" definition to double it from under 5000 lines to under 10,000. Perhaps it's time to consider doing that in pan's distributed sources as well? Altho a 10,000 lines "smallish" is equally arbitrary. Maybe it should be 12k, 15k, 20k? Similarly for "mediumish". 20k seems a bit low for modern usage. Maybe 25k, 30k or 50k? Tho if it's not a still-image that pan can display probably auto-save-dialog is better anyway. Personally I'd propose say 12k smallish, 25k mediumish. I'd call that much more sensible in a modern context altho maybe still on the conservative side. Anyone for say 20k and 50k, or even larger? I oppose killing the tests entirely and would consider say 50k/100k arguably /too/ high, as I doubt most folks would be happy with pan unexpectedly and without a dialog downloading whole multi-gig DVD ISO sizes, say. The other possibility would be adding smallish/mediumish sizes to options, presumably upping their defaults to at least my proposed 12k/25k in the process. That arguably makes more sense than hard-coding it. But while I can easily patch the hard-codes and could just as easily submit them for upstream inclusion after this discussion, options-coding is beyond my skill level so that sort of patch would need to be done by someone else. Meanwhile, anyone want to argue for changes to the in-subject extensions test or the in-group-name pictures test? -- 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
