all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Copying preserves font-lock-face
@ 2006-09-23  0:43 Nick Roberts
  2006-09-23 16:12 ` martin rudalics
  2006-09-23 18:01 ` Richard Stallman
  0 siblings, 2 replies; 15+ messages in thread
From: Nick Roberts @ 2006-09-23  0:43 UTC (permalink / raw)



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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-23  0:43 Copying preserves font-lock-face Nick Roberts
@ 2006-09-23 16:12 ` martin rudalics
  2006-09-24  6:13   ` Nick Roberts
  2006-09-23 18:01 ` Richard Stallman
  1 sibling, 1 reply; 15+ messages in thread
From: martin rudalics @ 2006-09-23 16:12 UTC (permalink / raw)
  Cc: emacs-devel

 > 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)

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-23  0:43 Copying preserves font-lock-face Nick Roberts
  2006-09-23 16:12 ` martin rudalics
@ 2006-09-23 18:01 ` Richard Stallman
  2006-09-25 22:32   ` Kevin Rodgers
  1 sibling, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2006-09-23 18:01 UTC (permalink / raw)
  Cc: emacs-devel

    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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-23 16:12 ` martin rudalics
@ 2006-09-24  6:13   ` Nick Roberts
  2006-09-24  9:43     ` martin rudalics
  0 siblings, 1 reply; 15+ messages in thread
From: Nick Roberts @ 2006-09-24  6:13 UTC (permalink / raw)
  Cc: emacs-devel

 > 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-24  6:13   ` Nick Roberts
@ 2006-09-24  9:43     ` martin rudalics
  2006-09-24 21:07       ` Nick Roberts
                         ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: martin rudalics @ 2006-09-24  9:43 UTC (permalink / raw)
  Cc: emacs-devel

 > 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?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-24  9:43     ` martin rudalics
@ 2006-09-24 21:07       ` Nick Roberts
  2006-09-25  2:22       ` Miles Bader
  2006-09-25  3:17       ` Richard Stallman
  2 siblings, 0 replies; 15+ messages in thread
From: Nick Roberts @ 2006-09-24 21:07 UTC (permalink / raw)
  Cc: emacs-devel

 > 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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-24  9:43     ` martin rudalics
  2006-09-24 21:07       ` Nick Roberts
@ 2006-09-25  2:22       ` Miles Bader
  2006-09-25  3:17       ` Richard Stallman
  2 siblings, 0 replies; 15+ messages in thread
From: Miles Bader @ 2006-09-25  2:22 UTC (permalink / raw)
  Cc: Nick Roberts, emacs-devel

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-24  9:43     ` martin rudalics
  2006-09-24 21:07       ` Nick Roberts
  2006-09-25  2:22       ` Miles Bader
@ 2006-09-25  3:17       ` Richard Stallman
  2006-09-25 22:02         ` Chong Yidong
  2 siblings, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2006-09-25  3:17 UTC (permalink / raw)
  Cc: nickrob, emacs-devel

`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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-25  3:17       ` Richard Stallman
@ 2006-09-25 22:02         ` Chong Yidong
  2006-09-26 15:41           ` Richard Stallman
  0 siblings, 1 reply; 15+ messages in thread
From: Chong Yidong @ 2006-09-25 22:02 UTC (permalink / raw)
  Cc: martin rudalics, nickrob, emacs-devel

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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-23 18:01 ` Richard Stallman
@ 2006-09-25 22:32   ` Kevin Rodgers
  2006-09-26 15:41     ` Richard Stallman
  0 siblings, 1 reply; 15+ messages in thread
From: Kevin Rodgers @ 2006-09-25 22:32 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-25 22:02         ` Chong Yidong
@ 2006-09-26 15:41           ` Richard Stallman
  2006-09-26 17:02             ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2006-09-26 15:41 UTC (permalink / raw)
  Cc: rudalics, nickrob, emacs-devel

    > 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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-25 22:32   ` Kevin Rodgers
@ 2006-09-26 15:41     ` Richard Stallman
  2006-10-02  4:04       ` Richard Stallman
  0 siblings, 1 reply; 15+ messages in thread
From: Richard Stallman @ 2006-09-26 15:41 UTC (permalink / raw)
  Cc: emacs-devel

    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?

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-26 15:41           ` Richard Stallman
@ 2006-09-26 17:02             ` Stefan Monnier
  2006-09-26 22:10               ` Richard Stallman
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2006-09-26 17:02 UTC (permalink / raw)
  Cc: rudalics, Chong Yidong, nickrob, emacs-devel

>     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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-26 17:02             ` Stefan Monnier
@ 2006-09-26 22:10               ` Richard Stallman
  0 siblings, 0 replies; 15+ messages in thread
From: Richard Stallman @ 2006-09-26 22:10 UTC (permalink / raw)
  Cc: rudalics, cyd, nickrob, emacs-devel

    > 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.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Copying preserves font-lock-face
  2006-09-26 15:41     ` Richard Stallman
@ 2006-10-02  4:04       ` Richard Stallman
  0 siblings, 0 replies; 15+ messages in thread
From: Richard Stallman @ 2006-10-02  4:04 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2006-10-02  4:04 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-23  0:43 Copying preserves font-lock-face Nick Roberts
2006-09-23 16:12 ` martin rudalics
2006-09-24  6:13   ` Nick Roberts
2006-09-24  9:43     ` martin rudalics
2006-09-24 21:07       ` Nick Roberts
2006-09-25  2:22       ` Miles Bader
2006-09-25  3:17       ` Richard Stallman
2006-09-25 22:02         ` Chong Yidong
2006-09-26 15:41           ` Richard Stallman
2006-09-26 17:02             ` Stefan Monnier
2006-09-26 22:10               ` Richard Stallman
2006-09-23 18:01 ` Richard Stallman
2006-09-25 22:32   ` Kevin Rodgers
2006-09-26 15:41     ` Richard Stallman
2006-10-02  4:04       ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.