GNU bug report logs - #8384
24.0.50; Yanking and text properties

Previous Next

Full log

Message #8 received at 8384 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 8384 <at> debbugs.gnu.org
Subject: Re: bug#8384: 24.0.50; Yanking and text properties
Date: Mon, 04 Apr 2011 21:53:39 +0100

On 30/03/11 23:26, Stephen Berman wrote:
> 1. emacs -Q
> 2. Enter text in a buffer and select it, e.g.: `C-x b a RET test C-SPC C-a'
> 3. Put a face or display text property on the selected text, e.g.: `M-o b'
> 4. Put the propertized text on the kill ring: `C-SPC C-e M-w'.
> 5. Yank it in another buffer: `C-x b b RET C-y'
> =>  The yanked text in buffer b is propertized as in buffer a.
>
> Now repeat steps 2 and 3, and instead of repeating step 4, double-click
> on the text with mouse-1 to make it the primary selection, and instead
> of repeating step 5, do `C-x b b RET<mouse-2>' to yank that selection.
> =>  The yanked text in buffer b is not propertized.
>
> Is this difference between the two types of yanking a programming bug or
> a feature (of the primary selection?) that is AFAICS undocumented and
> hence a doc bug?

Hmm. I'd be inclined to consider the inconsistency a bug, - if C-w/M-y 
sequences are property-preserving intraprocess*, so too should be 
select/middleclick sequences, really.

* properties were always lost AFAIK once the data went "all the way 
outside" to other processes, though technically emacs Could Do Better 
there on several platforms via the multi-format support in relevant 
window system clipboad and selection protocols.

> The comment by Glenn Morris in bug#8376
> (http://permalink.gmane.org/gmane.emacs.bugs/45480) suggests the former,
> namely, that yanking by C-y should also not preserve text properties.
> Note, however, that mouse-yank-at-click behaves like C-y and not like
> mouse-yank-primary.  (Or is it only font-locking, not face and display
> properties,

I think it's only the font-locking if I'm understanding the arguments 
correctly (which I may presently not), the font-locking properties are 
after all dynamic things, not something the user sets - i.e. if you 
yanked some python code into a python docstring (or some entirely 
separate sphinx rst file) you presumably wouldn't want them preserved, 
the correct thing to do is let the inserted text be rehighlighted 
according to the locally applicable rules if any.

I guess it would also be possible to "freeze" font-locking into static 
face properties. Not something I'd personally want to happen unless I 
asked for it - though consider too the way word processors now tend to 
offer "paste special..." options (related to the aforementioned multi 
format support), i.e. there are nowadays established ways for apps to 
offer both formatted and unformatted variants of text to paste in on our 
three major window systems.  The development work involved is nontrivial 
though, at least in my estimation.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.