Re: Question about copy-region-as-kill

[Kim F. Storm]

John Wiegley <address@hidden> writes:

> >>>>> On Mon Apr  8, Stefan writes:
> 
> > I think this points to a good compromise: strip any property whose
> > value is the same across the whole copied text.
> 
> This still does not solve the problem of copying the read-only
> property that's attached to Eshell prompts.

Maybe read-only is special...?
Does it ever make sense to yank a read-only property into a buffer?
If not, it doesn't make sense to ever copy that property.

> 
> Why can't a mode author decide to inhibit property copying in his
> buffer?  I still haven't seen a convincing argument for denying me a
> buffer-local configuration variable.
> 

I agree, but this doesn't solve the problem in general...

Consider:

- copy text in one major mode buffer and paste it into another
  major mode buffer.

In this case, it sometimes makes sense to copy face properties
(e.g. from a C to an RTF file), while it doesn't make sense
in other cases, (e.g. from an RTF file to a C file).

- copy text into a buffer with font-lock enabled

In this case, the font-lock should take care of fontifying
the inserted text, ignoring any previous fontification...

- copy text from a buffer with font-lock to a buffer without

This is similar to the first case, so in some cases with
does make sense, but in other cases it doesn't.


I don't say that this is a complete solution, but at least
two buffer-local variables are needed IMHO:

* remove-text-properties-on-copy
A list of text-properties to be removed when copying text
from this buffer (nil=none, t=all)

* remove-text-properties-on-insert
A list of text-properties to be removed when inserting text
into this buffer (nil=none, t=all)


kill-ring-save, copy-region-as-kill, and kill-region should
look at these.


I also considered having this:

* remove-font-lock-properties-on-copy
If non-nil, text-properties set by font-lock are automatically
removed on copy.

But this isn't really needed (or possible); I don't think we really
know whether a specific property was added by font-locking or added
explicitly by the user.  However, IMO it doesn't really seem to make
much sense to have both font-locking and the user adding properties as
well.  So when font-locking is turned on in a buffer, it seems to
make sense to set both of these variables to t (remove all).


> John
> 
> _______________________________________________
> Emacs-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> 
> 

-- 
Kim F. Storm <address@hidden> http://www.cua.dk