Hrvoje Niksic <hniksic(a)arsdigita.com> writes:
> (defun ansi-color-unfontify-region (beg end &rest
xemacs-stuff)
> "Replacement function for `font-lock-default-unfontify-region'.
> When font-lock is active in a buffer, you cannot simply add face
> text-properties to the buffer. Font-lock will remove the face
> text-property using `font-lock-unfontify-region-function'.
I don't think this is the case under XEmacs. font-lock uses the
text-property functions, which in turn touch only the extents they
know about. If you create a new extent and apply a face to it,
font-lock will not touch it.
Well, in Emacs it works like this: when text is inserted and overlays
are added, they are not touched by font-lock. When strings with text
properties are inserted, however, these text properties will be removed.
This is relevant for ansi-color.el: when colors are added via
ansi-color-apply-on-region, extents or overlays are used. No problem.
When colors are added to string via ansi-color-apply and these strings
are inserted into a buffer, font-lock-default-unfontify-region will
remove *all* face text properties in Emacs.
I looked at the implementation of font-lock-default-unfontify-region
in XEmacs. It calls font-lock-remove-face, and there:
(put-nonduplicable-text-property start end 'face nil)
(put-nonduplicable-text-property start end 'font-lock nil))
That looks as if all face text properties are removed, just like in
Emacs. The font-lock text property is not used to prevent this.
> (defun ansi-color-get-face-1 (ansi-code)
> "Get face definition from `ansi-color-map'.
> ANSI-CODE is used as an index into the vector."
> (condition-case nil
> (aref ansi-color-map ansi-code)
> ('args-out-of-range nil)))
^ this quote is not needed.
Cool, I'll do that.
Alex.