* bug#8384: 24.0.50; Yanking and text properties
@ 2011-03-30 22:26 Stephen Berman
2011-04-04 20:53 ` David De La Harpe Golden
0 siblings, 1 reply; 4+ messages in thread
From: Stephen Berman @ 2011-03-30 22:26 UTC (permalink / raw
To: 8384
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8384: 24.0.50; Yanking and text properties
2011-03-30 22:26 bug#8384: 24.0.50; Yanking and text properties Stephen Berman
@ 2011-04-04 20:53 ` David De La Harpe Golden
2011-04-05 5:16 ` Eli Zaretskii
0 siblings, 1 reply; 4+ messages in thread
From: David De La Harpe Golden @ 2011-04-04 20:53 UTC (permalink / raw
To: Stephen Berman; +Cc: 8384
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8384: 24.0.50; Yanking and text properties
2011-04-04 20:53 ` David De La Harpe Golden
@ 2011-04-05 5:16 ` Eli Zaretskii
2012-08-07 4:53 ` Chong Yidong
0 siblings, 1 reply; 4+ messages in thread
From: Eli Zaretskii @ 2011-04-05 5:16 UTC (permalink / raw
To: David De La Harpe Golden; +Cc: 8384, stephen.berman
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#8384: 24.0.50; Yanking and text properties
2011-04-05 5:16 ` Eli Zaretskii
@ 2012-08-07 4:53 ` Chong Yidong
0 siblings, 0 replies; 4+ messages in thread
From: Chong Yidong @ 2012-08-07 4:53 UTC (permalink / raw
To: Eli Zaretskii; +Cc: 8384, stephen.berman
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-08-07 4:53 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-30 22:26 bug#8384: 24.0.50; Yanking and text properties Stephen Berman
2011-04-04 20:53 ` David De La Harpe Golden
2011-04-05 5:16 ` Eli Zaretskii
2012-08-07 4:53 ` Chong Yidong
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.