How *not* to highlight

How *not* to highlight

[Juliusz Chroboczek]

Hello,

I was thinking how to keep Gnus from highlighting when some face stuff
has already been done, e.g. by a MIME decoder.  The problem is that if
the preprocessor changed some faces, then the Gnus highlighting
functions will just undo its work.

What I currently do is to check in the function
gnus-article-maybe-highlight whether

   (text-property-not-all (point-min) (point-max) 'face nil)

in the article buffer.  If it is the case, no highlighting is done.

Of course, this is not the right approach.  This means that if a face
has been changed, say, in the body of the article, then neither the
headers nor the signature will be highlighted.  Furthermore, it does
not inhibit spurious highlighting in the summary buffer.

I've thought about doing a similar check in the function
`gnus-add-text-properties', but then any function that sets text
faces would have to make sure that those will not be overridden
later.  Or should I add a function `gnus-set-text-face', which would
be called by all the highlighting functions?

By the way, I believe that this modification should find its way into
the distribution of Gnus.  It does not cost much, and as highlighting
is only there for esthetics, a preprocessor should be able to override
it.

Just if you're interested: I need this for some character set support
that I've added to TM and RMIME.  Feel free to browse

    http://www.dcs.ed.ac.uk/home/jec/charset/


                                        J. Chroboczek

Re: How *not* to highlight

[Per Abrahamsen]

You could use overlays instead of text properties.  That way, you
could have both highlighting and native characters simultaneously.  

It would probably be cleaner to do it the other way around, change
Gnus to use overlays for highlighting.  

You'd need some kind of emulation library, as Emacs and XEmacs use
different APIs for overlayes.  XEmacs use a more general and powerful
abstraction called `extents'.  It looks like it would be simple to
build the overlay API on top of the extent API, but I haven't tried.
The other way around would be impossible.

No Emacs vs. XEmacs flames, please!

Re: How *not* to highlight

[Juliusz Chroboczek]

In article <rjenj9ksdy.fsf@kolmogorov.dina.kvl.dk>,
  Per Abrahamsen <abraham@dina.kvl.dk> writes:

PA> You could use overlays instead of text properties.  That way, you
PA> could have both highlighting and native characters simultaneously.  

Well...  The whole point is that I need to pass multi-language text in
strings (TM expects to be able to do so -- it was designed for Mule).
I can do this with text properties (or extents), but not, as far as I
know, with overlays.

Right now, I've simply overridden the defalias in gnus-vis.el with

(defun gnus-put-text-property (start end property value &optional object)
  (if (and (eq 'face property)
           (text-property-not-all start end 'face nil))
      nil
    (put-text-property start end property value object)))

and everything seems to work.  Or is this evil in any way (except
insofar as mucking around with L.I.'s code is blasphemy, of course)?

                                        J. Chroboczek

P.S. So I'm reading this message by NNTP from Denmark, replying
through SMTP to Norway...  I have some problems grasping this Internet
thing, somehow.

Re: How *not* to highlight

[Lars Magne Ingebrigtsen]

Juliusz Chroboczek <jec@dcs.ed.ac.uk> writes:

> I was thinking how to keep Gnus from highlighting when some face stuff
> has already been done, e.g. by a MIME decoder.  The problem is that if
> the preprocessor changed some faces, then the Gnus highlighting
> functions will just undo its work.

Right.  Would it be possible to do the normal Gnus highlighting stuff
before doing the MIME decode face thingies?  

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."