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.

Attachment: signature.asc
Description: PGP signature

Reply via email to