GNU bug report logs - #40951
Weird highlighting

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40951 in the body.
You can then email your comments to 40951 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: submit <at> debbugs.gnu.org (The Gnus Bugfixing Girls + Boys)
Subject: Weird highlighting
Date: Wed, 29 Apr 2020 08:52:37 +0800

[Message part 1 (text/plain, inline)]

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

[Message part 2 (message/rfc822, inline)]

From: Martin Ward <martin <at> gkc.org.uk>
Subject: Re: How NASA does software testing and QA (Functionize)
Date: Tue, 28 Apr 2020 17:05:17 +0800

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.

[Message part 3 (text/plain, inline)]

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

Message #8 received at 40951 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 40951 <at> debbugs.gnu.org
Subject: Re: bug#40951: Weird highlighting
Date: Wed, 29 Apr 2020 09:44:56 +0200

積丹尼 Dan Jacobson <jidanni <at> 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 <at> 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.

Message #13 received at 40951 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 40951 <at> debbugs.gnu.org
Subject: Re: bug#40951: Weird highlighting
Date: Thu, 30 Apr 2020 01:50:25 +0800

>>>>> "KLG" == Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
KLG> 積丹尼 Dan Jacobson <jidanni <at> 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?

Message #16 received at 40951 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Cc: 40951 <at> debbugs.gnu.org
Subject: Re: bug#40951: Weird highlighting
Date: Fri, 01 May 2020 20:44:13 +0200

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

>>>>>> "KLG" == Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> KLG> 積丹尼 Dan Jacobson <jidanni <at> 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.

Message #19 received at 40951 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 40951 <at> debbugs.gnu.org,
 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#40951: Weird highlighting
Date: Wed, 05 Aug 2020 13:19:49 +0200

Kévin Le Gouguec <kevin.legouguec <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.