bug#8384: 24.0.50; Yanking and text properties

bug#8384: 24.0.50; Yanking and text properties

[Stephen Berman]

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?  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, that aren't supposed to be preserved any more?  Note also
that if other text properties, e.g. invisible or intangible, are applied
in the first recipe, yanking with C-y does not preserve these.)

In GNU Emacs 24.0.50.1 (i686-suse-linux-gnu, GTK+ Version 2.20.1)
 of 2011-03-30 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10800000
configured using `configure  '--without-toolkit-scroll-bars' 'CFLAGS=-g -O2 -fno-optimize-sibling-calls''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

bug#8384: 24.0.50; Yanking and text properties

[David De La Harpe Golden]

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.

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.

bug#8384: 24.0.50; Yanking and text properties

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

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

It just involves replacing buffer-substring-no-properties with
buffer-substring in deactivate-mark.  I agree that this inconsistency
with C-w/M-w might as well be fixed, so I did that in the trunk.