emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: M-w, then C-y. C-y inserts text properties that aren't on original.


From: Alan Mackenzie
Subject: Re: M-w, then C-y. C-y inserts text properties that aren't on original.
Date: Sun, 21 Feb 2010 21:16:18 +0000
User-agent: Mutt/1.5.9i

Hi, Eli,

On Sat, Feb 20, 2010 at 11:02:39AM +0200, Eli Zaretskii wrote:
> > Date: Fri, 19 Feb 2010 14:35:13 +0000
> > Cc: address@hidden
> > From: Alan Mackenzie <address@hidden>

> > `insert-for-yank' carries on, and calls
> > `remove-yank-excluded-properties' which deliberately changes
> > 'category properties into other properties.

> > Presumably there was some special case in the distant past which
> > required this transformation.  It is surely wrong in the general case
> > - yanking into a buffer shouldn't add text properties which weren't
> > in the original - surely?

> > I'm going to try and track down that special case.  It looks like
> > I'll have to fix the inserted string in CC Mode by hand.

> The reason for this behavior is this change:

>     2002-04-27  Richard M. Stallman  <address@hidden>

>           * subr.el (insert-for-yank): Replace `category' property
>           with whatever properties it stands for.

> The discussion that led to this change starts here:

>   http://lists.gnu.org/archive/html/emacs-devel/2002-04/msg00648.html

> You will find there the reason for the change (buttons in *Help*
> buffers, and the way we put the mouse-face property on them).

Thanks for the info.

> I wonder if we could make the code which replaces `category' with what
> it stands for, with a slightly less general code that replaces only
> those values of `category' that are used for buttons.  Or some similar
> change which will make that feature more focused on the problem it
> needs to solve.

That idea seems horrible to me.  ;-)

> I added a comment in `remove-yank-excluded-properties' explaining what
> do we do that for and pointing to the above URL for details.

The root cause of this mess is the confusion in text properties.  Text
properties (as opposed to overlays) become part of the text they're
applied to, yet they're mostly used (e.g. for font locking) in situations
where they're not intrinsically part of the text.

It would be better if these uses could use overlays, then copying the
string would ignore the overlay.  Yet the manual warns against using lots
of overlays, which are apparently worse implemented than text properties.
Also some properties with special meanings aren't special in overlays.

It would be good if "Somebody" could elevate overlays to the same
standard as text properties, so that we could move nearly everything over
to using overlays.

-- 
Alan Mackenzie (Nuremberg, Germany).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]