article highlighting in pgnus-0.13

article highlighting in pgnus-0.13

[John H Palmieri]

GNU Emacs 20.3.1 (sparc-sun-solaris2.5.1, X toolkit) of Thu Aug 27 1998 on darwin

Hi,

Sometime between version 0.10 and 0.13 of pgnus, the highlighting of
some mail messages has changed.  For example, in the recent message to
the ding list from Bill White (reproduced below for your enjoyment),
the main text (starting "I've added gnus-article-decode-charset")
appears entirely in italics, as though it were a signature.  Is this
happening to anyone else?

I'm a bit confused by this.  If I give Emacs the command

  (add-hook 'gnus-article-display-hook 'gnus-article-highlight-signature)

then I get this bad italicizing.  If I don't give Emacs this command,
but while reading the article I hit `W H s' to run
gnus-article-highlight-signature, I *don't* get the bad italicizing.
Oddly enough, the signature is italized no matter what.  For your
information, at this point, gnus-article-display-hook is set to:

'(gnus-article-decode-charset
  gnus-article-decode-rfc1522
  gnus-article-hide-headers-if-wanted
  gnus-article-hide-boring-headers
  gnus-article-maybe-highlight)

This is all quite repeatable: I can use add-hook and remove-hook to
toggle the presence of gnus-article-highlight-signature, depending on
whether I want too much text in italics.

Any explanations?

Here's an example of a troublesome message, including the headers.
(Lars' response behaved the same way.)

From: Bill White <billw@wolfram.com>
Subject: Re: Pterodactyl Gnus v0.9 is released
X-From-Line: owner-ding@hpc.uh.edu Tue Sep  1 16:09 EST 1998
Received: from dagger.nd.edu (nd.edu [129.74.250.101])
	by darwin.helios.nd.edu (8.8.8/8.8.8) with ESMTP id QAA18860
	for <jpalmier@darwin.helios.nd.edu>; Tue, 1 Sep 1998 16:09:39 -0500 (EST)
Received: from e-math.ams.org (e-math.ams.org [130.44.194.100])
	by dagger.nd.edu (8.8.8/SMS 2.0.4-beta-2) with SMTP id QAA01564
	for <John.H.Palmieri.2@nd.edu>; Tue, 1 Sep 1998 16:09:36 -0500 (EST)
Received: by e-math.ams.org; id AA09872; Tue, 1 Sep 1998 17:09:36 -0400
Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id PAT30132; Tue, 1 Sep 1998 15:40:25 -0500
Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 01 Sep 1998 16:07:29 -0500 (CDT)
Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id QAA14175 for <ding@hpc.uh.edu>; Tue, 1 Sep 1998 16:07:19 -0500 (CDT)
Received: from dragonfly.wolfram.com (root@dragonfly.wolfram.com [140.177.10.12])
	by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id RAA26648
	for <ding@gnus.org>; Tue, 1 Sep 1998 17:07:12 -0400 (EDT)
Received: from wolfram.com (billw@banshee.wolfram.com [140.177.4.4])
	by dragonfly.wolfram.com (8.8.8/8.8.8) with ESMTP id QAA29268;
	Tue, 1 Sep 1998 16:06:43 -0500 (CDT)
Received: (from billw@localhost)
	by wolfram.com (8.8.5/8.8.5) id QAA07375;
	Tue, 1 Sep 1998 16:06:32 -0500
To: ding@gnus.org
Cc: Michael Welsh Duggan <md5i@cs.cmu.edu>
References: <m37lzqmq0i.fsf@sparky.gnus.org> <kig4suusbjv.fsf@jagor.srce.hr> <m3r9xyzavi.fsf@sparky.gnus.org> <87soieqrmh.fsf@mharnois.workgroup.net> <m3u32uw82k.fsf@sparky.gnus.org> <m2ogt2njeq.fsf@altair.xemacs.org> <m3pvdha4te.fsf@sparky.gnus.org> <m2k93pmoki.fsf@altair.xemacs.org> <m3ogt1zam9.fsf@sparky.gnus.org> <m3iuj9e67r.fsf@zaphod.synnet.de> <m3d89hz64w.fsf@sparky.gnus.org> <m3u32r3g1r.fsf@zaphod.synnet.de> <v1t90k37eqt.fsf@peoria.mt.cs.cmu.edu>
Date: 01 Sep 1998 16:06:32 -0500
In-Reply-To: Michael Welsh Duggan's message of "Tue, 01 Sep 1998 20:35:44 GMT"
Message-Id: <ruo67f7fspz.fsf@banshee.wolfram.com>
X-Mailer: Pterodactyl Gnus v0.11/Emacs 20.3
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: owner-ding@hpc.uh.edu
Precedence: list
X-Majordomo: 1.94.jlt7
Content-Type: text/plain; charset="iso-2022-jp"
X-Content-Length: 1373
Lines: 50
Xref: darwin.helios.nd.edu mail.gnus:3343

I've added gnus-article-decode-charset to my
gnus-article-display-hook, which works great, and I'm using the
"fixed" font, which is a rather small, very pleasing sans-serif.

The Japanese characters below display as 3 empty boxes when I'm in the
fixed font. When I switch to the atrociously ugly standard fontset via
the menu item "Mule->Set Font/Fontset->Fontset->standard: 16-dot
medium", I can see the 3 J characters in their full glory.

Is it possible to see the J characters while using the "fixed" font?

I'm using:

- GNU Emacs 20.3.1 (i586-unicent-linux-gnu, X toolkit) of Thu Aug 20
  1998 on banshee
- Pterodactyl Gnus v0.11

Thanks -

Bill
-- 
Bill White
billw@wolfram.com
http://www.wolfram.com/~billw

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

> Kai Haberzettl <khaberz@synnet.de> writes:
> 
> > Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> > 
> > > Kai Haberzettl <khaberz@synnet.de> writes:
> > 
> > > > With 0.10, I still have to type 'W M w' to get the
> > > > japanese letters. Then it works perfectly though. 
> > > 
> > > Phew!  I was starting to think I was hallucinating...
> > 
> > With 0.13 the japanese characters are gone again. Instead I get 
> > [**iso-2022-jp charset **] 日本語
> 
> Even after a `W M c' or a `M-t'?  Japanese glyphs were displayed for
> me in your post...
> 
> -- 
> Michael Duggan
> (md5i@cs.cmu.edu)
> .

Re: article highlighting in pgnus-0.13

[Karl Kleinpaste]

John H Palmieri <John.H.Palmieri.2@nd.edu> writes:
> GNU Emacs 20.3.1 (sparc-sun-solaris2.5.1, X toolkit) of Thu Aug 27 1998 on darwin
> Sometime between version 0.10 and 0.13 of pgnus, the highlighting of
> some mail messages has changed.  For example, in the recent message to
> the ding list from Bill White (reproduced below for your enjoyment),
> the main text (starting "I've added gnus-article-decode-charset")
> appears entirely in italics, as though it were a signature.  Is this
> happening to anyone else?

For the record, no unusual signature italicization happens for me; the 
signature is detected correctly after the "--" and the latter half of
the article is signature-italicized, from "Bill White\nbillw@wolfram.com"
on down.

- RH5.1 Linux
- XEmacs 20.4 [mule-less], from RH contrib *.rpm
- pgnus 0.13
- gnus-article-display-hook consists of:
  (gnus-article-decode-charset
   gnus-article-decode-rfc1522
   gnus-article-hide-headers-if-wanted
   gnus-article-hide-boring-headers
   gnus-article-treat-overstrike
   gnus-article-maybe-highlight
   gnus-article-display-x-face
   gnus-article-highlight-citation
   gnus-article-emphasize
   gnus-article-date-lapsed
   gnus-article-hide-pgp
   gnus-smiley-display)

Perhaps order is (erroneously) significant, for -maybe-highlight placement?

Re: article highlighting in pgnus-0.13

[Michael Welsh Duggan]

John H Palmieri <John.H.Palmieri.2@nd.edu> writes:

> GNU Emacs 20.3.1 (sparc-sun-solaris2.5.1, X toolkit) of Thu Aug 27 1998 on darwin
> 
> Hi,
> 
> Sometime between version 0.10 and 0.13 of pgnus, the highlighting of
> some mail messages has changed.  For example, in the recent message to
> the ding list from Bill White (reproduced below for your enjoyment),
> the main text (starting "I've added gnus-article-decode-charset")
> appears entirely in italics, as though it were a signature.  Is this
> happening to anyone else?
> 
> I'm a bit confused by this.  If I give Emacs the command
> 
>   (add-hook 'gnus-article-display-hook 'gnus-article-highlight-signature)
> 
> then I get this bad italicizing.  If I don't give Emacs this command,
> but while reading the article I hit `W H s' to run
> gnus-article-highlight-signature, I *don't* get the bad italicizing.

I have encountered the same, in a different context.  It happens when
I do not have MIME turned on, and I use `M W c' to decode the message.

-- 
Michael Duggan
(md5i@cs.cmu.edu)
.

Re: article highlighting in pgnus-0.13

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

> I have encountered the same, in a different context.  It happens when
> I do not have MIME turned on, and I use `M W c' to decode the message.

The `decode-coding-region' function totally messes up all text props.
I don't know what to do about that.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: article highlighting in pgnus-0.13

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <md5i@cs.cmu.edu> writes:
> 
> > I have encountered the same, in a different context.  It happens when
> > I do not have MIME turned on, and I use `M W c' to decode the message.
> 
> The `decode-coding-region' function totally messes up all text props.
> I don't know what to do about that.

The only really good solutions at this point (until they fix
decode-coding-region') are to either remove the text properties, or
re-highlight the buffer after decoding.

-- 
Michael Duggan
(md5i@cs.cmu.edu)
.

Re: article highlighting in pgnus-0.13

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <md5i@cs.cmu.edu> writes:
> 
> > I have encountered the same, in a different context.  It happens when
> > I do not have MIME turned on, and I use `M W c' to decode the message.
> 
> The `decode-coding-region' function totally messes up all text
> props.  I don't know what to do about that.

Lars, does the same thing happen under XEmacs?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!"
"They are my innards! I will not have them misread by a poseur!"

Re: article highlighting in pgnus-0.13

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

> The only really good solutions at this point (until they fix
> decode-coding-region') are to either remove the text properties, or
> re-highlight the buffer after decoding.

Ick.  Would it be possible to write some sort of function that would
note all the text props on all the characters, and then be able to
restore the props after en/decoding?  Hm.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: article highlighting in pgnus-0.13

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <md5i@cs.cmu.edu> writes:
> 
> > The only really good solutions at this point (until they fix
> > decode-coding-region') are to either remove the text properties, or
> > re-highlight the buffer after decoding.
> 
> Ick.  Would it be possible to write some sort of function that would
> note all the text props on all the characters, and then be able to
> restore the props after en/decoding?  Hm.

Maybe.  You would have to use markers, since you don't know how many
characters the text is going to expand into.  I can have a go at
writing something.  (It will be a good opportunity to see if markers
survive `decode-coding-region', since text properties don't.)

-- 
Michael Duggan
(md5i@cs.cmu.edu)
.

Re: article highlighting in pgnus-0.13

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > The `decode-coding-region' function totally messes up all text
> > props.  I don't know what to do about that.
> 
> Lars, does the same thing happen under XEmacs?

I haven't noticed anything like that, so I would guess not.  The text
that changes from un-encoded to encoded doesn't inherit the text props
from the un-encoded text, though.

Under Emacs 20.3, the entire region that `encode-coding-region' is run
on is, well, messed up.  Sometimes it all gets one of the props that
were used somewhere in the text, sometimes it gets no props.  In Emacs
20.4 I understand that the function will remove all the props entirely
since it's "too difficult" to preserve the props.

*sigh*

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: article highlighting in pgnus-0.13

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

> Maybe.  You would have to use markers, since you don't know how many
> characters the text is going to expand into.  I can have a go at
> writing something.  (It will be a good opportunity to see if markers
> survive `decode-coding-region', since text properties don't.)

I would be surprised if markers survived.  If they are, that could be
exploited.

A different approach would be to save all the text in the region (in a
string or a temp buffer), encode the region, and then compare the
saved region with what you have, and copy the text props over where
matches are made.

Or something.

Do you want to take a whack at either approaches?  I'd be muchu
grateful.  In fact, if something like this were available, I'd submit
it to RMS for inclusion in Emacs 20.4.
`save-text-properties-encode-coding-region'?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: article highlighting in pgnus-0.13

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > > The `decode-coding-region' function totally messes up all text
> > > props.  I don't know what to do about that.
> > 
> > Lars, does the same thing happen under XEmacs?
> 
> I haven't noticed anything like that, so I would guess not.

I ask this because I notice no code in that function to attempt to
preserve the extents.  Does the function get called under XEmacs?

> The text that changes from un-encoded to encoded doesn't inherit the
> text props from the un-encoded text, though.

Can you be more specific?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Speak softly and carry a +6 two-handed sword.

Re: article highlighting in pgnus-0.13

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Michael Welsh Duggan <md5i@cs.cmu.edu> writes:
> 
> > Maybe.  You would have to use markers, since you don't know how many
> > characters the text is going to expand into.  I can have a go at
> > writing something.  (It will be a good opportunity to see if markers
> > survive `decode-coding-region', since text properties don't.)
> 
> I would be surprised if markers survived.  If they are, that could be
> exploited.
> 
> A different approach would be to save all the text in the region (in a
> string or a temp buffer), encode the region, and then compare the
> saved region with what you have, and copy the text props over where
> matches are made.
> 
> Or something.
> 
> Do you want to take a whack at either approaches?  I'd be muchu
> grateful.  In fact, if something like this were available, I'd submit
> it to RMS for inclusion in Emacs 20.4.
> `save-text-properties-encode-coding-region'?  :-)

I'll give it a whack.  Of course, in 20.4, if we are lucky,
decode-coding-region will be fixed w/respect to text properties.
Hm...  Maybe I will take a look at the code in that and see what it
looks like.

-- 
Michael Duggan
(md5i@cs.cmu.edu)
.

Re: article highlighting in pgnus-0.13

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> I ask this because I notice no code in that function to attempt to
> preserve the extents.  Does the function get called under XEmacs?

Yup.

> > The text that changes from un-encoded to encoded doesn't inherit the
> > text props from the un-encoded text, though.
> 
> Can you be more specific?

If you have some unencoded text that's nicely highlighted, and then
you run encode-coding-region on the buffer, the text that replaces the
unencoded text is not highlighted.

Uhm.  There may be some terminology problems in the previous
paragraphs.  What is "encoded" and what is "unencoded" in a MULE
context? 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: article highlighting in pgnus-0.13

[Lars Magne Ingebrigtsen]

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

> I'll give it a whack.

Great!

> Of course, in 20.4, if we are lucky,
> decode-coding-region will be fixed w/respect to text properties.

>From what Handa said, that doesn't seem to be likely.

> Hm...  Maybe I will take a look at the code in that and see what it
> looks like.

I can't see why it shouldn't be fixable.  I mean, one only has to
touch the text that is actually encoded and not the ascii stuff, so
I see no logical reason why the text props go amiss.  Unless it's
coded really badly.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: article highlighting in pgnus-0.13

[Michael Welsh Duggan]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > I ask this because I notice no code in that function to attempt to
> > preserve the extents.  Does the function get called under XEmacs?
> 
> Yup.
> 
> > > The text that changes from un-encoded to encoded doesn't inherit the
> > > text props from the un-encoded text, though.
> > 
> > Can you be more specific?
> 
> If you have some unencoded text that's nicely highlighted, and then
> you run encode-coding-region on the buffer, the text that replaces the
> unencoded text is not highlighted.
> 
> Uhm.  There may be some terminology problems in the previous
> paragraphs.  What is "encoded" and what is "unencoded" in a MULE
> context? 

Yeah, you got it a little backwards.

In MULE-speak, as far as I can tell, encoded text is text encoded
using a certain coding system.  Decoded (or unencoded) text is in
MULE's native format (and hence can be displayed in the correct font,
etc.).  In general, when reading a file, Emacs decodes into a native
format, and then encodes back into a coding system when writing back.

-- 
Michael Duggan
(md5i@cs.cmu.edu)
.