bug#8384: 24.0.50; Yanking and text properties

[Eli Zaretskii]

> Date: Mon, 04 Apr 2011 21:53:39 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> Cc: 8384@debbugs.gnu.org
> 
> > 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.

It could be a bug, or it could be a side effect of the implementation,
because the text we select with a mouse is treated very differently
from the text we put on the kill ring.

However, since we have an internal alist where we store all our
selections, we should be able in principle to paste local selections
with all their text properties.  Would someone please trace through
x-own-selection-internal when selecting, and then through
x-get-selection-internal when pasting with the mouse, and see why the
local selections we store in Vselection_alist lose their text
properties?

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

Right, but since we keep our local copy of the selection, which in
this case should be a string, we don't necessarily _need_ to lose the
text properties.

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

It's only about font-lock, and thus not relevant to this discussion.

> I guess it would also be possible to "freeze" font-locking into static 
> face properties.

At first glance, this doesn't make sense to me.  If the target buffer
has font-lock enabled, it will delete/override such faces on the spot
anyway.  So to support such a feature, someone should first present a
convincing use case.

> though consider too the way word processors now tend to offer "paste
> special..." options

AFAIU, "Paste special" options are for _reformatting_ the selection
into an equivalent (for some value of ``equivalent''), but different
formatting.  E.g., reformat text with colors into the equivalent HTML
representation.  That includes stripping all the formatting as one of
the possibilities.  But it does not include _addition_ of formatting,
so seems unrelated to converting the fontification properties to
hard-coded colors.

Anyway, this last issue is not related to this bug report, so it
should get its own thread.