On Tue, Jan 11, 2022 at 05:53:45PM -0800, Kevin J. McCarthy wrote: > On Tue, Jan 11, 2022 at 03:32:09PM -0600, Derek Martin wrote: > > OK but do you agree that behavior is wrong? :) It's one header, > > regardless of the wrapping... > > I'll have to think more closely about it. I do agree that the matching on > the folded line overriding the previous 'color header' match is confusing. > I don't believe the fix is hard, either.
FWIW/TLDR, I think as a matter of principle it should be fixed, and I doubt there can be any compelling arguments (beyond not being willing to volunteer the time to do it, which is a good one) that it shouldn't. I won't be heartbroken if it doesn't get fixed since I have config that works, but I do think not fixing the inconsistency makes Mutt suck just a little bit more... Now, the details: > However, it's not just about wrong vs. right I do agree--wrong is wrong, but there are two other questions to answer. There's the question of, "Does this provide useful functionality for some real-world use case?" I think the answer is that it does not. As you yourself said, the behavior is confusing, which does not lend itself to real-world use. As such the behavior is, I think, clearly broken. > but also about precedence of the behavior, and I believe this one > goes back to 1.5.21. If I make the change, I may then have > long-time users reporting a "genuine" regression. To me this argument is a much weaker one--wrong is wrong, and depending on a bug is a bug. :) I don't think this is one of the two questions... not precisely anyway (see below). Also, this DID work correctly (i.e. as I believe it should work), in for example 1.4.2.3 (I did actually check). So this IS a genuine regression... just one that no one has apparently noticed (or rather, reported) for a very, very long time. I didn't do the binary search to see where it stopped, I'll trust your suggestion that it was 1.5.21. :) [FWIW this IS something I have noticed on occasion that has been bugging me for a long while... but it didn't happen enough to distract me enough from what I was doing to actually look into it. Lately it has though, and I understand exactly why: As my professional role and responsibilities have expanded, so too have the number of mail threads I've been on with larger recipient lists. Otherwise, the messages I send and receive very typically have at most one or two people, and/or a mailing list. Not enough to warrant wrapping of the recipient headers, and therefore triggering this bug.] The second question is the matter of consequences: If you correct the (I think) clearly broken behavior, what is the impact on anyone affected? Well, in the worst case scenario, where someone actually is depending on this behavior (which I think is pretty unlikely, given much of the above), they'll just have to fix probably one or two color commands in their muttrc, or else some headers may be the wrong color. Admittedly a minor annoyance--not enough, I think, to offset the behavior being correct. In probably the vast majority of cases, it will require no action, either because the user isn't using this feature at all, or because they actually intended it to work as it did in the 1.4 era, and just never noticed or cared enough to bother to report that it didn't, like me. Now, for the bonus round: FWIW (particularly with this fixed) I think hdrdefault is redundant, and could actually be removed, though that would force some users to change their muttrc (so I'm not suggesting that, just pointing it out). However, assuming it's implemented as I imagine (I still haven't looked at the code, FWIW) it does reduce the regex comparisons required by 1, providing a slight optimization. Although, arguably, it would have exactly the same effect if the regex evaluation was optimized according to this python-like pseudo code: rule_applied = None foreach rule in rules: # Optimize the "match all" rule... # Prolly document that "." is shorthand for "match everything # by default" and don't try to be too clever about what other # regexes to optimize... if rule.regex == ".": # everything matches "." -- don't bother checking rule_applied = rule else: if rule.regex matches text: rule_applied = rule # all rules checked--apply the last match. if rule_applied: apply rule_applied In practice, I doubt this matters enough for anyone to notice the optimization, but possibly with lots of rules on slow hardware... Nah, still probably not. :) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature