Bug: Gnus uses face gnus-cite-1 for non-cited text

Bug: Gnus uses face gnus-cite-1 for non-cited text

[Tassilo Horn]

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

Hello,

sometimes when I follow up and yank an article Gnus uses the wrong face
(gnus-cite-1) for my own, non-cited text. I made a screenshot of this
bug [1]. As you can see the whole paragraph starting with "Sorry" is
displayed with gnus-cite-1, whereas all my other paragraphs are
displayed with the default face.

I made some tests with some mails of this group. The face that is used
for the paragraphs is noted in the brackets.

--8<---------------cut here---------------start------------->8---
Newsgroups: gmane.emacs.gnus.user,gmane.emacs.gnus.general
Subject: Re: POP SSL conexion failed
Gcc: nnfolder+archive:sent-messages
From: Tassilo Horn <tassilo@member.fsf.org>
--text follows this line--
Leo <sdl.web@gmail.com> writes:

> On 2007-01-19, Leo said:

e.e,. e,.e bi,.i [default face]

>> On 2007-01-13, Leo said:
>>
>>> I am getting this error a few times a day. Any ideas?

e,.ed m ez,.e e ,e,. [default face]

>> A backtrace:
>>
>> ,----
>> | Debugger entered--Lisp error: (error "POP SSL connexion failed")
>> |   signal(error ("POP SSL connexion failed"))
>> |   error("POP SSL connexion failed")
>> |   pop

ei.,iipip. [gnus-cite-4]

>> | 3-open-server("pop.gmail.com" 995)
>> | pop3-movemail("~/.emacs-mail-crash-box") mail-source-fetch-pop((pop
>> | :server "pop.gmail.com" :port 995 :user "sdl.web@gmail.com"
>> | :password "******" :stream ssl) #[(file orig-file) "Â\bÃÄ\b .?..
>

e.,e e,.e. [default face]

> Help!
>
> Is someone else seeing this error?

e.,e,.edz e.e. [default face]
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
Newsgroups: gmane.emacs.gnus.general
Cc: Daiki Ueno <ueno@unixuser.org>
Subject: Re: [pgg.el] Flashes of raw message
Gcc: nnfolder+archive:sent-messages
From: Tassilo Horn <tassilo@member.fsf.org>
--text follows this line--
Daiki Ueno <ueno@unixuser.org> writes:

>>>>>> In <enbp7i$1q0$1@sea.gmane.org> 
>>>>>>	Ralf Angeli <angeli@caeruleus.net> wrote:

bla bla [default face]

>> > with up-to-date CVS Emacs and No Gnus and the settings
>> > (require 'pgg)
>> > (setq mm-verify-option 'known)

e.e,. be,. c iikwmub [default face]

>> > in .gnus, the raw message is shown for a split second when an
>> > encrypted article like
>> > <news:microsoft-free.871wmg1ov8.fsf@youngs.au.com> is opened.  Can
>> > this be remedied somehow?

hyhyfh [default face]

>> Unless you saw the thread on emacs-pretest-bug, I might add that the
>> culprit is the `sit-for' call in `pgg-gpg-wait-for-completion' which
>> triggers a redisplay.

ip. dip. i [gnus-cite-2]

>> Passing t as the NODISP argument does not help.  (So I'm not sure if
>> there is an Emacs bug as well.)  Using `sleep-for' instead of
>> `sit-for' does help.

i.pi dti .m [default face]

> I think the right fix is to bind inhibit-redisplay in mml2015-pgg-*
> functions, since pgg-gpg-* functions should not affect the display
> behavior.  If you are using No Gnus, PGG is becoming obsolete by EasyPG,
> though.

g cti.p ti m.pmt [gnus-cite-1]

> Even at the moment, you will see this problem (?) fixed if you install
> it.

foo bar [default face]
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Footnotes: 
[1] http://www.tsdh.de/~heimdall/images/gnus-cite-1.jpg

No Gnus v0.6
GNU Emacs 22.0.93.1 (i686-pc-linux-gnu, GTK+ Version 2.10.9)
 of 2007-02-06 on baldur
200 news.gmane.org InterNetNews NNRP server INN 2.4.1 ready (posting ok).


[-- Attachment #2: User settings --]
[-- Type: application/emacs-lisp, Size: 8765 bytes --]

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Katsumi Yamaoka]

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

>>>>> In <87tzxzsenz.fsf@baldur.tsdh.de> Tassilo Horn wrote:

> sometimes when I follow up and yank an article Gnus uses the wrong face
> (gnus-cite-1) for my own, non-cited text. I made a screenshot of this
> bug [1]. As you can see the whole paragraph starting with "Sorry" is
> displayed with gnus-cite-1, whereas all my other paragraphs are
> displayed with the default face.

Showing the local value of `font-lock-keywords' in the message
buffer and the value of `message-cite-prefix-regexp' would be
helpful.  In addition, have you changed the value of
`message-cite-prefix-regexp' or added/removed some faces to/from
`gnus-cite-face-list'?

Currently the behavior of `gnus-message-citation-mode' is decided
by those values as of time when Gnus is compiled.  So, customizing
those options will not affect the behavior, or it might cause a
trouble if anything.  Well, the following patch may possibly do
the trick.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 447 bytes --]

--- gnus-cite.el~	2007-01-24 07:12:47 +0000
+++ gnus-cite.el	2007-02-07 01:42:02 +0000
@@ -1126,10 +1126,12 @@
 				     "\\)"))
 			   limit t)
     (let ((cdepth
+	   (min
 	   (length (apply 'concat
 			  (split-string
 			   (match-string-no-properties 0)
-			   "[ \t [:alnum:]]+"))))
+			   "[ \t [:alnum:]]+")))
+	   gnus-message-max-citation-depth))
 	  (mlist (make-list (* (1+ gnus-message-max-citation-depth)
 			       2)
 			    0)))

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Katsumi Yamaoka]

>>>>>> In <87tzxzsenz.fsf@baldur.tsdh.de> Tassilo Horn wrote:

>> sometimes when I follow up and yank an article Gnus uses the wrong face
>> (gnus-cite-1) for my own, non-cited text. I made a screenshot of this
>> bug [1]. As you can see the whole paragraph starting with "Sorry" is
>> displayed with gnus-cite-1, whereas all my other paragraphs are
>> displayed with the default face.

The cause of your problem may possibly come from putting unused
gnus-cite-* faces on the region `(0 0)', which should not be in
Emacs buffers.  Now I've fixed the code in question in the trunk.

Regards,

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Tassilo Horn]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

Hi Katsumi,

I updated my checkout half an hour ago, but still the bug is present.

See for example this follow up:

--8<---------------cut here---------------start------------->8---
Newsgroups: gmane.emacs.pretest.bugs,gmane.emacs.gnus.general
Subject: Re: TRAMP copies binary files incorrectly
Gcc: nnfolder+archive:sent-messages
From: Tassilo Horn <tassilo@member.fsf.org>
--text follows this line--
Kenichi Handa <handa@m17n.org> writes:

>> (nreverse result)) (insert (apply 'concat (nreverse result))))
>> (delete-region (point) end)))))) --- 220,226 ---- (or (markerp end)
>> (setq end (set-marker (make-marker) end))) (goto-char start) (if
>> enable-multibyte-characters !  (mapc #'(lambda (x) (insert
>> (uude

i,.i. [gnus-cite-2]

e.,i.i. [default face]
--8<---------------cut here---------------end--------------->8---

> Showing the local value of `font-lock-keywords' in the message
> buffer

(t
 ((#[(limit)
     "`\x18\214~\210eb\210\303\304\305	!\306Q\307\310#\203\x1a

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Tassilo Horn]

Hi again,

it seems some control-characters garbled part of my last posting, so
here is the cut off part (with control chars replaced with their printed
representaton).

> Showing the local value of `font-lock-keywords' in the message
> buffer

(t
 ((#[(limit)
     "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
     [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\([Tt]o:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
     4]
   (1 'message-header-name)
   (2 'message-header-to nil t))
  (#[(limit)
     "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
     [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\(^[GBF]?[Cc][Cc]:\\|^[Rr]eply-[Tt]o:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
     4]
   (1 'message-header-name)
   (2 'message-header-cc nil t))
  (#[(limit)
     "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
     [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\([Ss]ubject:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
     4]
   (1 'message-header-name)
   (2 'message-header-subject nil t))
  (#[(limit)
     "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
     [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\([Nn]ewsgroups:\\|Followup-[Tt]o:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
     4]
   (1 'message-header-name)
   (2 'message-header-newsgroups nil t))
  (#[(limit)
     "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
     [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\([A-Z][^: \n	]+:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
     4]
   (1 'message-header-name)
   (2 'message-header-other nil t))
  (#[(limit)
     "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
     [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\(X-[A-Za-z0-9-]+:\\|In-Reply-To:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
     4]
   (1 'message-header-name)
   (2 'message-header-name))
  ("^\\(--text follows this line--\\)$" 1 'message-separator)
  ((lambda
     (limit)
     (re-search-forward
      (concat "^\\(" message-cite-prefix-regexp "\\).*")
      limit t))
   (0 'message-cited-text))
  ("<#/?\\(multipart\\|part\\|external\\|mml\\|secure\\)[^>]*>"
   (0 'message-mml))
  (gnus-message-search-citation-line
   (1 'gnus-cite-1 prepend t)
   (2 'gnus-cite-2 prepend t)
   (3 'gnus-cite-3 prepend t)
   (4 'gnus-cite-4 prepend t)
   (5 'gnus-cite-5 prepend t)
   (6 'gnus-cite-6 prepend t)
   (7 'gnus-cite-7 prepend t)
   (8 'gnus-cite-8 prepend t)
   (9 'gnus-cite-9 prepend t)
   (10 'gnus-cite-10 prepend t)
   (11 'gnus-cite-11 prepend t)))
 (#[(limit)
    "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
    [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\([Tt]o:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
    4]
  (1 'message-header-name)
  (2 'message-header-to nil t))
 (#[(limit)
    "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
    [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\(^[GBF]?[Cc][Cc]:\\|^[Rr]eply-[Tt]o:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
    4]
  (1 'message-header-name)
  (2 'message-header-cc nil t))
 (#[(limit)
    "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
    [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\([Ss]ubject:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
    4]
  (1 'message-header-name)
  (2 'message-header-subject nil t))
 (#[(limit)
    "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
    [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\([Nn]ewsgroups:\\|Followup-[Tt]o:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
    4]
  (1 'message-header-name)
  (2 'message-header-newsgroups nil t))
 (#[(limit)
    "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
    [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\([A-Z][^: \n	]+:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
    4]
  (1 'message-header-name)
  (2 'message-header-other nil t))
 (#[(limit)
    "`^X\214~\210eb\210\303\304\305	!\306Q\307\310#\203^Z^@\n\311\224^^R^Hb\210)^H\nW\205)^@\303\312\n\310#)\207"
    [start mail-header-separator limit re-search-forward "^" regexp-quote "$" nil t 0 "^\\(X-[A-Za-z0-9-]+:\\|In-Reply-To:\\)[ 	]*\\(.+\\(\n[ 	].*\\)*\\)\n?"]
    4]
  (1 'message-header-name)
  (2 'message-header-name))
 ("^\\(--text follows this line--\\)$"
  (1 'message-separator))
 ((lambda
    (limit)
    (re-search-forward
     (concat "^\\(" message-cite-prefix-regexp "\\).*")
     limit t))
  (0 'message-cited-text))
 ("<#/?\\(multipart\\|part\\|external\\|mml\\|secure\\)[^>]*>"
  (0 'message-mml))
 (gnus-message-search-citation-line
  (1 'gnus-cite-1 prepend t)
  (2 'gnus-cite-2 prepend t)
  (3 'gnus-cite-3 prepend t)
  (4 'gnus-cite-4 prepend t)
  (5 'gnus-cite-5 prepend t)
  (6 'gnus-cite-6 prepend t)
  (7 'gnus-cite-7 prepend t)
  (8 'gnus-cite-8 prepend t)
  (9 'gnus-cite-9 prepend t)
  (10 'gnus-cite-10 prepend t)
  (11 'gnus-cite-11 prepend t)))

> and the value of `message-cite-prefix-regexp' would be helpful.

"\\([ 	]*[-_.[:word:]]+>+\\|[ 	]*[]>|}+]\\)+"

> In addition, have you changed the value of
> `message-cite-prefix-regexp' or added/removed some faces to/from
> `gnus-cite-face-list'?

No.

,----[ grep cite ~/.gnus.el ~/.emacs ]
| /home/heimdall/.gnus.el:(setq message-cite-function
| /home/heimdall/.gnus.el:      'message-cite-original-without-signature)
| /home/heimdall/.gnus.el:(setq gnus-cite-parse-max-size 100000)
`----

> Currently the behavior of `gnus-message-citation-mode' is decided
> by those values as of time when Gnus is compiled.  So, customizing
> those options will not affect the behavior, or it might cause a
> trouble if anything.  Well, the following patch may possibly do
> the trick.

Currently I didn't apply this patch, because in your follow up to
yourself you said you probably fixed the bug. Or was that another
change? Should I apply the patch below manually and check again?

> --- gnus-cite.el~	2007-01-24 07:12:47 +0000
> +++ gnus-cite.el	2007-02-07 01:42:02 +0000
> @@ -1126,10 +1126,12 @@
>  				     "\\)"))
>  			   limit t)
>      (let ((cdepth
> +	   (min
>  	   (length (apply 'concat
>  			  (split-string
>  			   (match-string-no-properties 0)
> -			   "[ \t [:alnum:]]+"))))
> +			   "[ \t [:alnum:]]+")))
> +	   gnus-message-max-citation-depth))
>  	  (mlist (make-list (* (1+ gnus-message-max-citation-depth)
>  			       2)
>  			    0)))

Bye,
Tassilo

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Katsumi Yamaoka]

>>>>> In <871wl2i4sf.fsf@baldur.tsdh.de> Tassilo Horn wrote:

> I updated my checkout half an hour ago, but still the bug is present.

[...]

>> Showing the local value of `font-lock-keywords' in the message
>> buffer

> (t
>  ((#[(limit)

[...]

>> and the value of `message-cite-prefix-regexp' would be helpful.

> "\\([ 	]*[-_.[:word:]]+>+\\|[ 	]*[]>|}+]\\)+"

Thanks.  But I found no oddity there.

> Currently I didn't apply this patch, because in your follow up to
> yourself you said you probably fixed the bug. Or was that another
> change? Should I apply the patch below manually and check again?

>> --- gnus-cite.el~	2007-01-24 07:12:47 +0000
>> +++ gnus-cite.el	2007-02-07 01:42:02 +0000
>> @@ -1126,10 +1126,12 @@

You have no need to try the patch, since I've already applied it
in the trunk.

Could you let me know the results of evaluating the following
two forms?  Note that both should be done in the line which is
highlighted with gnus-cite-* face unwillingly.  The results will
be put in the *Messages* buffer.

--8<---------------cut here---------------start------------->8---
(text-properties-at (point))

(mapcar 'overlay-properties (overlays-at (point)))
--8<---------------cut here---------------end--------------->8---

In addition, please check whether it is effective to evaluate
the following form in the message buffer (it might be useless if
you don't see the `field' property in the above results, though).

--8<---------------cut here---------------start------------->8---
(set (make-local-variable 'inhibit-field-text-motion) t)
--8<---------------cut here---------------end--------------->8---

Regards,

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Tassilo Horn]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

Hi Katsumi,

I tested with this posting:

--8<---------------cut here---------------start------------->8---
Newsgroups: gmane.emacs.pretest.bugs
Subject: Re: TRAMP copies binary files incorrectly
Gcc: nnfolder+archive:sent-messages
From: Tassilo Horn <tassilo@member.fsf.org>
--text follows this line--

> In a multibyte buffer, raw byte data, say 0x81, is
> represented not by that byte itself but by 0x20 added and
> with preceding special byte 0x9E (so the byte sequence is
> 0x9E 0xA1) t

I tested on this line [gnus-cite-1]

foo bar [default face]
--8<---------------cut here---------------end--------------->8---


> (text-properties-at (point))

==> (fontified t)

> (mapcar 'overlay-properties (overlays-at (point)))

==> ((face gnus-cite-1 evaporate t))

> In addition, please check whether it is effective to evaluate
> the following form in the message buffer (it might be useless if
> you don't see the `field' property in the above results, though).
>
> (set (make-local-variable 'inhibit-field-text-motion) t)

This didn't help, but as you said there was no field property set.

Bye,
Tassilo 
-- 
My opinions may have changed, but not the fact that I am right.

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Katsumi Yamaoka]

>>>>> In <87r6t0q5b6.fsf@baldur.tsdh.de>
>>>>>	Tassilo Horn <tassilo@member.fsf.org> wrote:

> I tested with this posting:

[...]

>> (text-properties-at (point))

> ==> (fontified t)

>> (mapcar 'overlay-properties (overlays-at (point)))

> ==> ((face gnus-cite-1 evaporate t))

What put this face should be `gnus-article-highlight-citation',
not `gnus-message-citation-mode'.  `gnus-message-citation-mode'
uses font-lock.  font-lock uses text properties, not overlays.
So, I think the culprit is not `gnus-message-citation-mode'.
Evaluating the `(gnus-kill-all-overlays)' form in the message
buffer will delete those faces (you can also add it to some
message-*-hook for the workaround).

I guess that those overlays are copied from the article buffer
for some reason.  Or don't you use `gnus-article-highlight-citation'
purposely in the message buffer?  I've used it like the following
in the past:

(let ((gnus-article-buffer (current-buffer)))
  (gnus-article-highlight-citation t))

Regards,

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Tassilo Horn]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

Hello Katsumi, [default face]

> What put this face should be `gnus-article-highlight-citation', not
> `gnus-message-citation-mode'.  `gnus-message-citation-mode' uses
> font-lock.  font-lock uses text properties, not overlays.  So, I think
> the culprit is not `gnus-message-citation-mode'.  Evaluating the
> `(gnus-kill-all-overlays)' form in the message buffer will delete
> those faces (you can also add it to some message-*-hook for the
> workaround).

This works indeed. [default face]

> I guess that those overlays are copied from the article buffer for
> some reason.  Or don't you use `gnus-article-highlight-citation'
> purposely in the message buffer?

No, I don't use that, at least I didn't modify Gnus to do it on my
own. [gnus-cite-1].

If the change Reiner introduced [1] uses this function, then I use it
implicitly. [gnus-cite-1, too]

Bye,     [default face]
Tassilo

Footnotes: 
[1] <v9y7os14zi.fsf@marauder.physik.uni-ulm.de>
-- 
* delYsid has mortgage, opportunity and penis in his score file.
<delYsid> thats pretty effective against spam
<Luke> aren't you worried about missing opportunities to mortgage
       your penis?

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Katsumi Yamaoka]

At last I found the cause; `message-cite-original-1' definitely
calls `gnus-article-highlight-citation'.  Oops!  The reason why
I took time so long is that I don't use `message-cite-original'
and I forgot to read the ChangeLog file.

Tassilo Horn <tassilo@member.fsf.org> writes:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> I guess that those overlays are copied from the article buffer for
>> some reason.  Or don't you use `gnus-article-highlight-citation'
>> purposely in the message buffer?
>
> No, I don't use that, at least I didn't modify Gnus to do it on my
> own. [gnus-cite-1].
>
> If the change Reiner introduced [1] uses this function, then I use it
> implicitly. [gnus-cite-1, too]
[...]
> Footnotes:
> [1] <v9y7os14zi.fsf@marauder.physik.uni-ulm.de>

`gnus-article-highlight-citation' is useless for message buffers
if `gnus-message-citation-mode' is enabled since those highlighting
is quite different; what `g-a-h-c' did are overridden by `g-m-c-m'.
Moreover, `g-a-h-c' has no effect for text edited afterward.  So,
I've simply removed it from message.el.

Regards,

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Tassilo Horn]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

Hello Katsumi,

> At last I found the cause; `message-cite-original-1' definitely calls
> `gnus-article-highlight-citation'.

Hm, are you sure this was the cause? I use a revision that has this
ChangeLog entry:                                     [default face]

,----
| 2007-02-09  Katsumi Yamaoka  <yamaoka@jpl.org>
| 
|         * message.el (message-cite-original-1): Don't call
|         gnus-article-highlight-citation.
| 
|         * gnus-cite.el (gnus-cite-parse): Work with two or more MS-type
|         citations; fix line count.
`----

> `gnus-article-highlight-citation' is useless for message buffers
> if `gnus-message-citation-mode' is enabled since those highlighting
> is quite different; what `g-a-h-c' did are overridden by `g-m-c-m'.
> Moreover, `g-a-h-c'

And this is still gnus-cite-1.

> has no effect for text edited afterward.  So, I've simply removed it
> from message.el.

Regards, [default face]
Tassilo
-- 
     My software never has bugs. It just develops random features.

Re: Bug: Gnus uses face gnus-cite-1 for non-cited text

[Tassilo Horn]

Oops! Stop, you're right. The bug seems fixed and the problem was me --
I forgot to restart emacs after updating gnus.

Thanks a lot,
Tassilo
-- 
     My software never has bugs. It just develops random features.