bug#40951: Weird highlighting

bug#40951: Weird highlighting

[積丹尼 Dan Jacobson]

[-- Attachment #1: Type: text/plain, Size: 115 bytes --]

Why does the
taking...:
line get different color (bad)
but the
A couple...:
line not? (good).
[pipe to procmail:]


[-- Attachment #2: Type: message/rfc822, Size: 1505 bytes --]

From: Martin Ward <martin@gkc.org.uk>
Subject: Re: How NASA does software testing and QA (Functionize)
Date: Tue, 28 Apr 2020 17:05:17 +0800
Message-ID: <87sggn6rw3.8.fsf@totally-fudged-out-message-id>

A couple of quotes from the article that I found depressing:

> Crumbley recommends the CMMI Institute's Capability Maturity Model
> Integration (CMMI) as a good process model.

CMMI defined five "maturity levels" starting at level 1: "Processes
unpredictable, poorly controlled and reactive."

So to say that you use "CMMI" just means you have decided which maturity
level your process is currently defined as.  You could be level 1 and happy
with it!

Crumbley does not say what level NASA's software development department has
currently reached, or what level they are aiming at nor what steps they are
taking to reach the desired level. Instead he says:

> We use the CMMI model as a tool to see how our software development
> practices compare with other industries

"Other industries" have woefully inadequate software development practices:
as exemplified in every issue of comp.risks!  Comparing yourself with them
just gives a false sense of security.  NASA's software requirements are so
much more stringent than the vast majority of other industries: on other
industries, if the software more-or-less works, only needs rebooting
occasionally and only has a few zero-day exploits per week, then the
software is considered to be a success. He does not even *mention* formal
methods.

[-- Attachment #3: Type: text/plain, Size: 149 bytes --]


No such bug when viewed in mutt.

Gnus v5.13
GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.11)
 of 2019-09-23, modified by Debian

bug#40951: Weird highlighting

[Kévin Le Gouguec]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

> Why does the
> taking...:
> line get different color (bad)
> but the
> A couple...:
> line not? (good).
> [pipe to procmail:]
>
> From: Martin Ward <martin@gkc.org.uk>
> Subject: Re: How NASA does software testing and QA (Functionize)
> Date: Tue, 28 Apr 2020 17:05:17 +0800 (22 hours, 29 minutes, 33 seconds ago)
>
> Crumbley does not say what level NASA's software development department has
> currently reached, or what level they are aiming at nor what steps they are
> taking to reach the desired level. Instead he says:
>
> No such bug when viewed in mutt.
>
> Gnus v5.13

I'd blame gnus-cite-attribution-suffix.  Try setting it to a regexp that
doesn't match "says:", then redisplay the article with 'g'.

That sounds like a tricky bug to fix.  On the one hand, I've seen many
false positives (i.e. lines highlighted because someone writes e.g. "the
manual/docstring/comment says:"), on the other hand I don't see how Gnus
could distinguish between a verb added deliberately by the article
author, and the same verb added automatically as part of the mail
client's citation boilerplate.

bug#40951: Weird highlighting

[積丹尼 Dan Jacobson]

>>>>> "KLG" == Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
KLG> 積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

KLG> on the other hand I don't see how Gnus could distinguish between a
KLG> verb added deliberately by the article author, and the same verb
KLG> added automatically as part of the mail client's citation
KLG> boilerplate.

Hmmm, well don't boilerplates have some @ and/or < and > etc. in them?

bug#40951: Weird highlighting

[Kévin Le Gouguec]

積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:

>>>>>> "KLG" == Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
> KLG> 積丹尼 Dan Jacobson <jidanni@jidanni.org> writes:
>
> KLG> on the other hand I don't see how Gnus could distinguish between a
> KLG> verb added deliberately by the article author, and the same verb
> KLG> added automatically as part of the mail client's citation
> KLG> boilerplate.
>
> Hmmm, well don't boilerplates have some @ and/or < and > etc. in them?

If we focus solely on Gnus's message.el, message-insert-citation-line
can be relied on to use whatever was in the "From" header.  From what I
gather from RFC 5322, that should at least include an "@" sign.

That only covers Gnus's "writes:" though.  Spelunking in lisp/gnus for
other verbs featured in gnus-cite-attribution-suffix, I get the
impression that other MUAs tend to follow suit, but that might be
wishful thinking.

Assuming false negatives (failing to highlight) on articles from
"non-conforming" MUAs are less annoying than false positives
(highlighting part of a line that's not introducing a citation) on
"conforming" ones, I'm still not sure where the right "fix" would
belong.

gnus-cite-attribution-suffix's job is to match just the final verb
before the citation, so I think it's fine the way it is.  There's
probably a way to teach gnus-article-highlight-citation that it
shouldn't apply gnus-cite-attribution-face to the whole line, but I'm
not familiar enough with the code to see how to go about it.

bug#40951: Weird highlighting

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> That only covers Gnus's "writes:" though.  Spelunking in lisp/gnus for
> other verbs featured in gnus-cite-attribution-suffix, I get the
> impression that other MUAs tend to follow suit, but that might be
> wishful thinking.

Yeah, the "says:" stuff can be anything, really.  

> Assuming false negatives (failing to highlight) on articles from
> "non-conforming" MUAs are less annoying than false positives
> (highlighting part of a line that's not introducing a citation) on
> "conforming" ones, I'm still not sure where the right "fix" would
> belong.

Both are pretty annoying, but I don't think there's realistically any
way to fix this to be better than it is.  Some AI analysis would be
handy.  :-)

So I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no