Copying preserves font-lock-face

Copying preserves font-lock-face

[Nick Roberts]

My jargon might be a bit wrong but here goes:

If I copy text with a face into a fontified buffer it gets a face according
to it's context e.g a word in a comment in c-mode to a keyword location
(face goes from font-lock-comment-face to font-lock-keyword-face)

If I copy text with a font-lock-face it keeps that property and doesn't acquire
the face appropriate to it's new location e.g text from the grep buffer with
font-lock-face `match' looks the same after being copied into a C file.  I
realise that I can remove font-lock-face with facemenu-remove-all but I don't
see why I should need to.

Is there a reason why font-lock-face should be preserved on copying?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Copying preserves font-lock-face

[martin rudalics]

 > If I copy text with a face into a fontified buffer it gets a face according
 > to it's context e.g a word in a comment in c-mode to a keyword location
 > (face goes from font-lock-comment-face to font-lock-keyword-face)
 >
 > If I copy text with a font-lock-face it keeps that property and doesn't acquire
 > the face appropriate to it's new location e.g text from the grep buffer with
 > font-lock-face `match' looks the same after being copied into a C file.  I
 > realise that I can remove font-lock-face with facemenu-remove-all but I don't
 > see why I should need to.

Does this happen with emacs -Q too?

(defun font-lock-default-unfontify-region (beg end)
   (remove-list-of-text-properties
    beg end (append
	    font-lock-extra-managed-props
	    (if font-lock-syntactic-keywords
		'(syntax-table face font-lock-multiline)
	      '(face font-lock-multiline)))))

removes _all_ face properties.  Hence, either the properties you mention
are not face properties or something goes wrong with fontification after
a buffer change.

 > Is there a reason why font-lock-face should be preserved on copying?

In some rare cases, I find it useful to see remnants of faces assigned
by font-lock when I copy a stretch of code to a plain text buffer.
Hence, in principle, preserving such face properties does not seem
wrong.  I do think, however, that, copying the `fontified' property by
default can be confusing.  Hence, I'd prefer something like

(defcustom yank-excluded-properties
   '(read-only invisible intangible field mouse-face help-echo local-map keymap
     yank-handler follow-link fontified)

Re: Copying preserves font-lock-face

[Richard Stallman]

    If I copy text with a font-lock-face it keeps that property and doesn't acquire
    the face appropriate to it's new location e.g text from the grep buffer with
    font-lock-face `match' looks the same after being copied into a C file.  I
    realise that I can remove font-lock-face with facemenu-remove-all but I don't
    see why I should need to.

    Is there a reason why font-lock-face should be preserved on copying?

Perhaps it should be preserved when copying into a non-font-lock
buffer, but discarded when copying into a buffer with font-lock
enabled.

Re: Copying preserves font-lock-face

[Nick Roberts]

 > Does this happen with emacs -Q too?

Yes.

 > (defun font-lock-default-unfontify-region (beg end)
 >    (remove-list-of-text-properties
 >     beg end (append
 > 	    font-lock-extra-managed-props
 > 	    (if font-lock-syntactic-keywords
 > 		'(syntax-table face font-lock-multiline)
 > 	      '(face font-lock-multiline)))))
 > 
 > removes _all_ face properties.  Hence, either the properties you mention
 > are not face properties or something goes wrong with fontification after
 > a buffer change.

Yes but face and font-lock-face are different character properties and I'm
talking about the latter.

 >  > Is there a reason why font-lock-face should be preserved on copying?
 > 
 > In some rare cases, I find it useful to see remnants of faces assigned
 > by font-lock when I copy a stretch of code to a plain text buffer.
 > Hence, in principle, preserving such face properties does not seem
 > wrong.

Are faces assigned by font-lock and font-lock-faces the same thing?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Copying preserves font-lock-face

[martin rudalics]

 > Yes but face and font-lock-face are different character properties and I'm
 > talking about the latter.

I don't understand where you get a `font-lock-face' (sic) property from
but you can add it to `font-lock-extra-managed-props'.

 >  >  > Is there a reason why font-lock-face should be preserved on copying?
 >  >
 >  > In some rare cases, I find it useful to see remnants of faces assigned
 >  > by font-lock when I copy a stretch of code to a plain text buffer.
 >  > Hence, in principle, preserving such face properties does not seem
 >  > wrong.
 >
 > Are faces assigned by font-lock and font-lock-faces the same thing?

`font-lock-apply-highlight' and the functions that append or prepend
text properties do things like (put-text-property start end 'face val),
hence they assign a `face' property, not a `font-lock-face' property.
Can you find out how a `font-lock-face' text property gets assigned on
your system?

Re: Copying preserves font-lock-face

[Nick Roberts]

 > I don't understand where you get a `font-lock-face' (sic) property from
 > but you can add it to `font-lock-extra-managed-props'.

According to the manual:

`font-lock-face'
     The `font-lock-face' property is the same in all respects as the
     `face' property, but its state of activation is controlled by
     `font-lock-mode'.

 > Can you find out how a `font-lock-face' text property gets assigned on
 > your system?

In grep I guess it's the line:

      (2 (list 'face nil 'font-lock-face grep-match-face))

from grep-mode-font-lock-keywords.

It's not only grep though, I have copied parts of the manual (into e-mail say)
and it gets displayed as large text e.g info-title-1.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Copying preserves font-lock-face

[Miles Bader]

martin rudalics <rudalics@gmx.at> writes:
>  > Yes but face and font-lock-face are different character properties and I'm
>  > talking about the latter.
>
> I don't understand where you get a `font-lock-face' (sic) property from
> but you can add it to `font-lock-extra-managed-props'.

Font-lock-mode arranges for `font-lock-face' properties to be
interpreted as `face' properties (using `char-property-alias-alist').

This allows a mode to _directly_ add face properties in a font-locked
buffer, and these face properties are safe from being overwritten by
font-lock-mode.  This to support modes which really want to do their own
ad-hoc facification (:-), while still allowing the user to turn face
display on or off using `M-x font-lock-mode' (etc).

-Miles

-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: Copying preserves font-lock-face

[Richard Stallman]

`font-lock-face' is used by major modes that "manually" implement
fontification.  They set up `font-lock-face' properties.

Font Lock mode uses `char-property-alias-alist' to cause
`font-lock-face' properties to be displayed as if they were `face'
properties.

So I guess we need to get rid of `font-lock-face' properties when
yanking, at least usually.  However, in buffers where all faces are
assigned "manually", perhaps we should instead convert them to `face'
properties.

Re: Copying preserves font-lock-face

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

> So I guess we need to get rid of `font-lock-face' properties when
> yanking, at least usually.

Sounds OK to me.

> However, in buffers where all faces are assigned "manually", perhaps
> we should instead convert them to `face' properties.

Such modes can probably manipulate yank-excluded-properties if
necessary.  I don't know of any mode where getting rid of the
font-lock-face would be wrong.

Re: Copying preserves font-lock-face

[Kevin Rodgers]

Richard Stallman wrote:
>     If I copy text with a font-lock-face it keeps that property and doesn't acquire
>     the face appropriate to it's new location e.g text from the grep buffer with
>     font-lock-face `match' looks the same after being copied into a C file.  I
>     realise that I can remove font-lock-face with facemenu-remove-all but I don't
>     see why I should need to.
> 
>     Is there a reason why font-lock-face should be preserved on copying?
> 
> Perhaps it should be preserved when copying into a non-font-lock
> buffer, but discarded when copying into a buffer with font-lock
> enabled.

On the topic of yanking fontified text into non-font-lock buffers,
I became annoyed when any following keyed text would inherit those
properties, so I put this in my .emacs file:

(defadvice yank (after rear-nonsticky activate)
   "Make all yanked text properties rear-nonsticky, unless Font Lock is on."
   (unless font-lock-mode
     (put-text-property (region-beginning) (region-end) 'rear-nonsticky t)))

-- 
Kevin

Re: Copying preserves font-lock-face

[Richard Stallman]

    > However, in buffers where all faces are assigned "manually", perhaps
    > we should instead convert them to `face' properties.

    Such modes can probably manipulate yank-excluded-properties if
    necessary.  I don't know of any mode where getting rid of the
    font-lock-face would be wrong.

Text mode is one.  Basically, any mode where font lock really does
nothing at all.  Certainly with Enriched mode on, we would not want
any faces to be lost.

I will do it.

Re: Copying preserves font-lock-face

[Richard Stallman]

    On the topic of yanking fontified text into non-font-lock buffers,
    I became annoyed when any following keyed text would inherit those
    properties, so I put this in my .emacs file:

    (defadvice yank (after rear-nonsticky activate)
       "Make all yanked text properties rear-nonsticky, unless Font Lock is on."
       (unless font-lock-mode
	 (put-text-property (region-beginning) (region-end) 'rear-nonsticky t)))

That code can't be entirely right, since the treatment of properties
not related to faces shouldn't depend on font-lock-mode.  Nonetheless,
you might be getting at a good point.  Perhaps insert-for-yank should
do this unconditionally for face properties only.

Does anyone disagree?

Re: Copying preserves font-lock-face

[Stefan Monnier]

>     Such modes can probably manipulate yank-excluded-properties if
>     necessary.  I don't know of any mode where getting rid of the
>     font-lock-face would be wrong.

> Text mode is one.  Basically, any mode where font lock really does
> nothing at all.

Why?

> Certainly with Enriched mode on, we would not want
> any faces to be lost.

Enriched mode doesn't use font-lock-face.


        Stefan

Re: Copying preserves font-lock-face

[Richard Stallman]

    > Certainly with Enriched mode on, we would not want
    > any faces to be lost.

    Enriched mode doesn't use font-lock-face.

That's right; it should be converted to `face'.

I implemented it already.  Everyone else can stop thinking about this
one now.

Re: Copying preserves font-lock-face

[Richard Stallman]

Does this patch give you good results?

*** subr.el	28 Sep 2006 15:05:32 -0400	1.528
--- subr.el	01 Oct 2006 23:38:37 -0400	
***************
*** 2195,2200 ****
--- 2195,2208 ----
  
      (unless (nth 2 handler) ;; NOEXCLUDE
        (remove-yank-excluded-properties opoint (point)))
+ 
+     ;; If inserted text has properties, mark them as rear-nonsticky.
+     (if (or (text-properties-at opoint)
+ 	    (and (< (1+ opoint) end)
+ 		 (>= (next-property-change (1+ opoint) nil end)
+ 		     end)))
+ 	(put-text-property opoint end 'rear-nonsticky t))
+ 
      (if (eq yank-undo-function t)  ;; not set by FUNCTION
  	(setq yank-undo-function (nth 3 handler))) ;; UNDO
      (if (nth 4 handler) ;; COMMAND