Question about copy-region-as-kill

Question about copy-region-as-kill

[John Wiegley]

Why does this function use `buffer-substring' instead of
`buffer-substring-no-properties'?  Isn't this just a historical flaw,
from when the latter function didn't exist?

I can't think of when I *ever* want properties copied to my kill ring.
Can we just change this, and thus obviate the primary reason why
people use overlays?

John

Re: Question about copy-region-as-kill

[Richard Stallman]

Most text properties are supposed to be killed and yanked.
Imagine editing a multi-font document.

Re: Question about copy-region-as-kill

[John Wiegley]

>>>>> On Thu Apr  4, RMS writes:

> Most text properties are supposed to be killed and yanked.  Imagine
> editing a multi-font document.

Shouldn't this be a property of the document, rather than a general
rule?

Perhaps there should be a buffer-local-variable
`copy-properties-on-kill'.  In the majority of cases, I think property
copying is the wrong thing to do.

This would also be a very trivial, isolated change.  Furthermore, you
could default the value of that variable to non-nil, if you really
want that as the default behavior.  And then, modes which DON'T want
property copying ever (like my emacs-wiki mode) could avoid it by
simply changing a local variable.

John

Re: Question about copy-region-as-kill

[Eli Zaretskii]

> From: John Wiegley <johnw@gnu.org>
> Date: Fri, 05 Apr 2002 14:39:24 -0700
> 
> >>>>> On Thu Apr  4, RMS writes:
> 
> > Most text properties are supposed to be killed and yanked.  Imagine
> > editing a multi-font document.
> 
> Shouldn't this be a property of the document, rather than a general
> rule?

If most uses of text yanking want this rule, I think it makes sense to
have it globally enabled.  Lisp programs which don't want that can
always remove the properties before inserting the text.

> In the majority of cases, I think property copying is the wrong
> thing to do.

FWIW, my impression is exactly the opposite.

Re: Question about copy-region-as-kill

[John Wiegley]

>>>>> On Sat Apr  6, Eli writes:

> If most uses of text yanking want this rule, I think it makes sense
> to have it globally enabled.  Lisp programs which don't want that
> can always remove the properties before inserting the text.

How can I control the behavior of C-y?

>> In the majority of cases, I think property copying is the wrong
>> thing to do.

> FWIW, my impression is exactly the opposite.

Well, I can't say much except that I've been bitten by copying them,
but haven't noticed the value of the flipside much.

Anyway, Emacs is all about flexibility, and not requiring a particular
modus just because "it's always done that".  How about that
buffer-local variable?

John

Re: Question about copy-region-as-kill

[Karl Eichwalder]

John Wiegley <johnw@gnu.org> writes:

>>> In the majority of cases, I think property copying is the wrong
>>> thing to do.
>
>> FWIW, my impression is exactly the opposite.
>
> Well, I can't say much except that I've been bitten by copying them,
> but haven't noticed the value of the flipside much.

The same counts for me.  Copying properties is annoying.  Only hackers
think regular users would like such a behavior.

> Anyway, Emacs is all about flexibility, and not requiring a particular
> modus just because "it's always done that".  How about that
> buffer-local variable?

That's the minimum (IMO).  Additionally I like to see a global toggle
to disable copying properties if not explicitly required by the user.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Question about copy-region-as-kill

[Kai Großjohann]

Karl Eichwalder <ke@gnu.franken.de> writes:

> The same counts for me.  Copying properties is annoying.  Only hackers
> think regular users would like such a behavior.

I wonder what do DTP and word processing programs do?  I guess if you
copy an italic word from one place to another it stays italic.

After Emacs moves in the wysiwyg direction, I guess that people used
to other wysiwyg programs would expect similar behavior, ie that text
properties are copied.  But then, I'm a hacker, so what do I know...

I guess that properties added by font-lock are different.  Hm.  On
the other hand, you could get the effect of htmlize.el by simply
doing C-x h M-w C-x b foo RET C-y to copy some program text into the
foo buffer (which presumably contains a wysiwyg-type document).
Doesn't that sound sweet?

kai
-- 
Silence is foo!

Re: Question about copy-region-as-kill

[Alex Schroeder]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I guess that properties added by font-lock are different.

To me, that sounds about right: If a text property was added by Emacs,
ie. font-lock, then chances are high that in another buffer the text
properties will be lost anyway (after saving and reloading, or when
the font-lock for the new buffer kicks in).  In this case, we might as
well remove the text-properties anyway.  And since such
text-properties are only added by a selected few packages, we could
add a list (special-text-properties?) of symbols to Emacs.  The
default value would be '(fontified) and probably some more.  When text
is yanked, any text covered by any of these text-properties will have
all of its text-properties stripped for that area.  Thus, if I kill
some text it gets stored with text-properties (thus you can also save
such a kill-ring to a file without loosing).  When a normal user yanks
such a text, however, all text properties (mostly the property 'face)
will be removed for all text areas covered by the 'fontified text
property -- this will undo face properties which font-lock added.

Alex.
-- 
http://www.emacswiki.org/

Re: Question about copy-region-as-kill

[Richard Stallman]

    > I guess that properties added by font-lock are different.

    To me, that sounds about right: If a text property was added by Emacs,
    ie. font-lock, then chances are high that in another buffer the text
    properties will be lost anyway (after saving and reloading, or when
    the font-lock for the new buffer kicks in).  In this case, we might as
    well remove the text-properties anyway.

That is a good point.  Perhaps therefore font-lock should create
overlays rather than text properties.  Overlays are not part of the
text, and won't be copied when the text is copied.

Re: Question about copy-region-as-kill

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> That is a good point.  Perhaps therefore font-lock should create
> overlays rather than text properties.  Overlays are not part of the
> text, and won't be copied when the text is copied.

As a practical matter, this may not be a good idea -- overlays seem to
be quite a bit more expensive than text properties.  I also think
text-properties are a better match with what font-lock does, modulo the
copying issue.

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: Question about copy-region-as-kill

[Karl Eichwalder]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I wonder what do DTP and word processing programs do?  I guess if you
> copy an italic word from one place to another it stays italic.

Yes and that's plain wrong--as a user I sufferd by this behavior.  If
you copy a word from a (bold) title line you don't want to stay the
word bold within your running text.

Only hackers believe that that's a feature.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Question about copy-region-as-kill

[Alan Shutko]

Karl Eichwalder <ke@gnu.franken.de> writes:

> Yes and that's plain wrong--as a user I sufferd by this behavior.  If
> you copy a word from a (bold) title line you don't want to stay the
> word bold within your running text.

OTOH, if you copy a book title which you marked in italics, you do
want the italics to come with.  If you copy a paragraph that you
carefully marked up with bold emphasis in places, courier font for
command text, and some underlines for good measure, you _also_ want
the properties to come with.

Clearly, the only real answer to this is to make it possible to choose
on a per-kill basis whether you want the properties to come with, and
let the user choose the default.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
The world needs more people like us and fewer like them.

Re: Question about copy-region-as-kill

[Karl Eichwalder]

Alan Shutko <ats@acm.org> writes:

> OTOH, if you copy a book title which you marked in italics, you do
> want the italics to come with.  If you copy a paragraph that you
> carefully marked up with bold emphasis in places, courier font for
> command text, and some underlines for good measure, you _also_ want
> the properties to come with.

Sometimes perhaps.  Properties might come with by default when you are
copying a whole entity (marked with "^^^^", keep italics and underline):

    <i>[...] you <u>also</u> want the properties to come with.</i>
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

But when copy a part only keep only some of them (underline, drop italics):

    <i>[...] you <u>also</u> want the properties to come with.</i>
             ^^^^^^^^^^^^^^^^^^^^

Or drop even italics:

    <i>[...] you <u>also</u> want the properties to come with.</i>
                                  ^^^^^^^^^^^^^^

> Clearly, the only real answer to this is to make it possible to choose
> on a per-kill basis whether you want the properties to come with, and
> let the user choose the default.

I do agree.

Tak Ota <Takaaki.Ota@am.sony.com> writes:

> I think non-hackers perceive things in WYSIWYG way, meaning if they
> copy bold test they expect to paste bold text as well.

As a writer using common word processor I always thought the
application cannot do better and wrote my custom marcos or invented
tricks:

    . copy affected text fragments into a DOS box
    . mark it there again and
    . paste it back in the application window.

> Only hackers perceive text as data structure consisting of two parts,
> essential character code portion and optional property (attribute)
> portion.

Some are different ;)

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Question about copy-region-as-kill

[Stefan Monnier]

> Sometimes perhaps.  Properties might come with by default when you are
> copying a whole entity (marked with "^^^^", keep italics and underline):
> 
>     <i>[...] you <u>also</u> want the properties to come with.</i>
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> But when copy a part only keep only some of them (underline, drop italics):
> 
>     <i>[...] you <u>also</u> want the properties to come with.</i>
>              ^^^^^^^^^^^^^^^^^^^^
> 
> Or drop even italics:
> 
>     <i>[...] you <u>also</u> want the properties to come with.</i>
>                                   ^^^^^^^^^^^^^^

I think this points to a good compromise: strip any property
whose value is the same across the whole copied text.


	Stefan

Re: Question about copy-region-as-kill

[John Wiegley]

>>>>> On Mon Apr  8, Stefan writes:

> I think this points to a good compromise: strip any property whose
> value is the same across the whole copied text.

This still does not solve the problem of copying the read-only
property that's attached to Eshell prompts.

Why can't a mode author decide to inhibit property copying in his
buffer?  I still haven't seen a convincing argument for denying me a
buffer-local configuration variable.

John

Re: Question about copy-region-as-kill

[Kim F. Storm]

John Wiegley <johnw@gnu.org> writes:

> >>>>> On Mon Apr  8, Stefan writes:
> 
> > I think this points to a good compromise: strip any property whose
> > value is the same across the whole copied text.
> 
> This still does not solve the problem of copying the read-only
> property that's attached to Eshell prompts.

Maybe read-only is special...?
Does it ever make sense to yank a read-only property into a buffer?
If not, it doesn't make sense to ever copy that property.

> 
> Why can't a mode author decide to inhibit property copying in his
> buffer?  I still haven't seen a convincing argument for denying me a
> buffer-local configuration variable.
> 

I agree, but this doesn't solve the problem in general...

Consider:

- copy text in one major mode buffer and paste it into another
  major mode buffer.

In this case, it sometimes makes sense to copy face properties
(e.g. from a C to an RTF file), while it doesn't make sense
in other cases, (e.g. from an RTF file to a C file).

- copy text into a buffer with font-lock enabled

In this case, the font-lock should take care of fontifying
the inserted text, ignoring any previous fontification...

- copy text from a buffer with font-lock to a buffer without

This is similar to the first case, so in some cases with
does make sense, but in other cases it doesn't.


I don't say that this is a complete solution, but at least
two buffer-local variables are needed IMHO:

* remove-text-properties-on-copy
A list of text-properties to be removed when copying text
from this buffer (nil=none, t=all)

* remove-text-properties-on-insert
A list of text-properties to be removed when inserting text
into this buffer (nil=none, t=all)


kill-ring-save, copy-region-as-kill, and kill-region should
look at these.


I also considered having this:

* remove-font-lock-properties-on-copy
If non-nil, text-properties set by font-lock are automatically
removed on copy.

But this isn't really needed (or possible); I don't think we really
know whether a specific property was added by font-locking or added
explicitly by the user.  However, IMO it doesn't really seem to make
much sense to have both font-locking and the user adding properties as
well.  So when font-locking is turned on in a buffer, it seems to
make sense to set both of these variables to t (remove all).


> John
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> 
> 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Question about copy-region-as-kill

[Eli Zaretskii]

On 9 Apr 2002, Kim F. Storm wrote:

> Maybe read-only is special...?
> Does it ever make sense to yank a read-only property into a buffer?

Does it ever make sense to consider read-only as a property of text--any 
text at all?  If not, perhaps read-only should not be a text property, 
but an overlay.

Re: Question about copy-region-as-kill

[Miles Bader]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> Does it ever make sense to consider read-only as a property of text--any 
> text at all?  If not, perhaps read-only should not be a text property, 
> but an overlay.

I think many people may prefer the text-property programming interface
anyway.  Anyway, yeah, it does make sense -- consider a form: it's
generally thought of as read-only with read/write fields in it.

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: Question about copy-region-as-kill

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Eli Zaretskii <eliz@is.elta.co.il> writes:
> > Does it ever make sense to consider read-only as a property of text--any 
> > text at all?  If not, perhaps read-only should not be a text property, 
> > but an overlay.
> 
> I think many people may prefer the text-property programming interface
> anyway.  Anyway, yeah, it does make sense -- consider a form: it's
> generally thought of as read-only with read/write fields in it.

I think using read-only property for this is perfectly valid, but still,
if you copy the form (or part of it) to another buffer, I guess it really
doesn't make sense to regard it as a form anymore.

Another property which I *hate* having copied is the mouse-face property.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Question about copy-region-as-kill

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > I think many people may prefer the text-property programming interface
> > anyway.  Anyway, yeah, it does make sense -- consider a form: it's
> > generally thought of as read-only with read/write fields in it.
> 
> I think using read-only property for this is perfectly valid, but still,
> if you copy the form (or part of it) to another buffer, I guess it really
> doesn't make sense to regard it as a form anymore.

I agree that read-only (and mouse-face &c) properties are annoying when
copied, and I'd be quite happy if they never were; I was just arguing
that _conceptually_, they really are `part of the text', not something
independent overlayed on top of it.

-Miles

-- 
Run away!  Run away!

Re: Question about copy-region-as-kill

[Eli Zaretskii]

On 9 Apr 2002, Kim F. Storm wrote:

> Another property which I *hate* having copied is the mouse-face property.

Perhaps that, too, should be an overlay.

Re: Question about copy-region-as-kill

[Richard Stallman]

    Does it ever make sense to consider read-only as a property of text--any 
    text at all?  If not, perhaps read-only should not be a text property, 
    but an overlay.

It might work ok to use overlays always for read-onliness,
but I see no a priori reason it should never be a text property.

Re: Question about copy-region-as-kill

[Richard Stallman]

It might be possible to divide all major modes into a few named
categories, such that we could design a reasonable plan for what to do
with text props on copying of text, given the category of the buffer
being copied from and the category of the buffer being copied to.

Here is a starting list of categories:

A. Buffers where properties are determined from the characters.
(E.g., programming language mode using font-lock, Rmail, and Info.)

B. Buffers where properties are put on by Lisp code but can't be
determined from the characters.  (E.g., the minibuffer, the output
of list-faces-display, and Shell mode).

C. Buffers which should have no text properties.
(E.g., programming language mode without font-lock).

D. Buffers where properties can be assigned by users.
(E.g., Enriched mode, and maybe Fundamental mode).

Perhaps all text properties should be discarded when copying into
buffers of categories A, B and C.  But what should be done with images
copied into these buffers?

Perhaps certain specific properties should be discarded when
copying into category D buffers.

Are any more alternative categories or subdivisions of them needed?

Re: Question about copy-region-as-kill

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> It might be possible to divide all major modes into a few named
> categories, such that we could design a reasonable plan for what to do
> with text props on copying of text, given the category of the buffer
> being copied from and the category of the buffer being copied to.

This scheme may cover perhaps 90% of all cases, so I still think having
buffer-local lists of properties to discard on copy/yank would provide
a (possible) solution for the last 10%...

> 
> Here is a starting list of categories:
> 
> A. Buffers where properties are determined from the characters.
> (E.g., programming language mode using font-lock, Rmail, and Info.)
> 
> B. Buffers where properties are put on by Lisp code but can't be
> determined from the characters.  (E.g., the minibuffer, the output
> of list-faces-display, and Shell mode).
> 
> C. Buffers which should have no text properties.
> (E.g., programming language mode without font-lock).
> 
> D. Buffers where properties can be assigned by users.
> (E.g., Enriched mode, and maybe Fundamental mode).
> 
> Perhaps all text properties should be discarded when copying into
> buffers of categories A, B and C.  But what should be done with images
> copied into these buffers?

Again, it depends...  E.g. if we enhance RMAIL to show small icons
for unread or urgent messages (or whatever), we don't want to copy
those images -- but if a mail message contains an image, we would
(probably) want to copy that (as an image).

> 
> Perhaps certain specific properties should be discarded when
> copying into category D buffers.
> 
Such as mouse-face and read-only...

> Are any more alternative categories or subdivisions of them needed?

Can't think of any, but I suppose there will be those 10% of special
cases which will never fit (entirely) into a specific category.

But what about (also) having a user command:

        yank-without-properties

which can be bound to C-Y (when supported) and C-x C-y?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Question about copy-region-as-kill

[Richard Stallman]

    Again, it depends...  E.g. if we enhance RMAIL to show small icons
    for unread or urgent messages (or whatever), we don't want to copy
    those images -- but if a mail message contains an image, we would
    (probably) want to copy that (as an image).

"Enhance RMAIL to show icons" is not a clear  description of a scenario.
Where would these icons go?  In which buffer?

    Can't think of any, but I suppose there will be those 10% of special
    cases which will never fit (entirely) into a specific category.

Talking about the possibility of unknown whatever does not help
sharpen the analysis.  Are there any interesting cases that you can
think of now?

    But what about (also) having a user command:

	    yank-without-properties

I dislike it very much.  It is far better to have a convenient
way to clear out text properties from the region.

Re: Question about copy-region-as-kill

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Again, it depends...  E.g. if we enhance RMAIL to show small icons
>     for unread or urgent messages (or whatever), we don't want to copy
>     those images -- but if a mail message contains an image, we would
>     (probably) want to copy that (as an image).
> 
> "Enhance RMAIL to show icons" is not a clear  description of a scenario.
> Where would these icons go?  In which buffer?

It might use an image property to show an icon _instead_ of a MIME attachment.
Now, if you copy the message to another buffer, do you want to still _see_
the icon instead of the MIME attachment, or do you want to see the "raw" text?

There may also be a mouse action associated with the icon, causing the MIME
attachment to be expanded (or saved or whatever).

I guess, it again depends on what the target buffer is.  If you are composing
a new message, it would make sense to just see the icon for the attachment,
but for other purposes, that may not be what you want...


> 
>     Can't think of any, but I suppose there will be those 10% of special
>     cases which will never fit (entirely) into a specific category.
> 
> Talking about the possibility of unknown whatever does not help
> sharpen the analysis.  Are there any interesting cases that you can
> think of now?

No, but images are a good example of something which may be problematic, e.g.
it does make sense to copy images between "document" buffers or mail buffers,
but not into a C or lisp buffer.

However, as I tried to explain, some images (e.g. a picture of my cat)
may be "true" images (which are part of the text/document), and other
images may be added by emacs lisp code (e.g. an icon for an attachment).

So I don't think you can make a general rule which will cover both.

> 
>     But what about (also) having a user command:
> 
> 	    yank-without-properties
> 
> I dislike it very much.  It is far better to have a convenient
> way to clear out text properties from the region.

I dislike it too, but at least it gives the user the final word!

Re: Question about copy-region-as-kill

[Richard Stallman]

    It might use an image property to show an icon _instead_ of a MIME attachment.
    Now, if you copy the message to another buffer, do you want to still _see_
    the icon instead of the MIME attachment, or do you want to see the "raw" text?

I don't know.

    I guess, it again depends on what the target buffer is.  If you are composing
    a new message, it would make sense to just see the icon for the attachment,
    but for other purposes, that may not be what you want...

Can you try to think further about this question?  Which kinds of
buffers would you want that icon to appear in?  Would it really work
to copy the attachment verbatim into an outgoing message?  Actually I
think not; it would require some other modification to turn into a
valid outgoing MIME attachment.

Perhaps these properties should never be copied into any other buffer.

    >     But what about (also) having a user command:
    > 
    > 	    yank-without-properties
    > 
    > I dislike it very much.  It is far better to have a convenient
    > way to clear out text properties from the region.

    I dislike it too, but at least it gives the user the final word!

The convenient way to clear out text properties also does that.

Re: Question about copy-region-as-kill

[Francesco Potorti`]

   	    yank-without-properties
   
   I dislike it very much.  It is far better to have a convenient
   way to clear out text properties from the region.

I use rmime.el.  This program automatically interprets some mime
contents of received mail, and displays them in the rmail buffer.

I often found myself copying that content and pasting it in a differnet
buffer, only to find that the yanked content was not the text I was
looking at, but rather the mime attachment.  This is very annoying, as
I do not know of a way to avoid it.  I just wanted to copy what was
visible on the rmail buffer.

Re: Question about copy-region-as-kill

[Per Abrahamsen]

John Wiegley <johnw@gnu.org> writes:

>>>>>> On Mon Apr  8, Stefan writes:
>
>> I think this points to a good compromise: strip any property whose
>> value is the same across the whole copied text.
>
> This still does not solve the problem of copying the read-only
> property that's attached to Eshell prompts.
>
> Why can't a mode author decide to inhibit property copying in his
> buffer? 

Gnus does that for message buffers:

From message-mode:

  ;; Mmmm... Forbidden properties...
  (add-hook 'after-change-functions 'message-strip-forbidden-properties
	    nil 'local)

The implementation of message-strip-forbidden-properties:

(defcustom message-strip-special-text-properties t
  "Strip special properties from the message buffer.

Emacs has a number of special text properties which can break message
composing in various ways.  If this option is set, message will strip
these properties from the message composition buffer.  However, some
packages requires these properties to be present in order to work.
If you use one of these packages, turn this option off, and hope the
message composition doesn't break too bad."
  :group 'message-various
  :type 'boolean)

(defconst message-forbidden-properties
  ;; No reason this should be clutter up customize.  We make it a
  ;; property list (rather than a list of property symbols), to be
  ;; directly useful for `remove-text-properties'.
  '(field nil read-only nil intangible nil invisible nil
	  mouse-face nil modification-hooks nil insert-in-front-hooks nil
	  insert-behind-hooks nil point-entered nil point-left nil)
  ;; Other special properties:
  ;; category, face, display: probably doesn't do any harm.
  ;; fontified: is used by font-lock.
  ;; syntax-table, local-map: I dunno.
  ;; We need to add XEmacs names to the list.
  "Property list of with properties.forbidden in message buffers.
The values of the properties are ignored, only the property names are used.")

(defun message-tamago-not-in-use-p (pos)
  "Return t when tamago version 4 is not in use at the cursor position.
Tamago version 4 is a popular input method for writing Japanese text.
It uses the properties `intangible', `invisible', `modification-hooks'
and `read-only' when translating ascii or kana text to kanji text.
These properties are essential to work, so we should never strip them."
  (not (and (boundp 'egg-modefull-mode)
	    (symbol-value 'egg-modefull-mode)
	    (or (memq (get-text-property pos 'intangible)
		      '(its-part-1 its-part-2))
		(get-text-property pos 'egg-end)
		(get-text-property pos 'egg-lang)
		(get-text-property pos 'egg-start)))))

(defun message-strip-forbidden-properties (begin end &optional old-length)
  "Strip forbidden properties between BEGIN and END, ignoring the third arg.
This function is intended to be called from `after-change-functions'.
See also `message-forbidden-properties'."
  (when (and message-strip-special-text-properties
	     (message-tamago-not-in-use-p begin))
    (remove-text-properties begin end message-forbidden-properties)))

Re: Question about copy-region-as-kill

[John Wiegley]

>>>>> On Tue Apr  9, Per writes:

> Gnus does that for message buffers:

>> From message-mode:

>   ;; Mmmm... Forbidden properties...
>   (add-hook 'after-change-functions
>   'message-strip-forbidden-properties
> 	    nil 'local)

Well, there's proof that somebody else needed it!  Although, their way
of solving it is so much uglier than a buffer-local variable...

John

Re: Question about copy-region-as-kill

[Tak Ota]

Sat, 06 Apr 2002 20:30:18 +0200: Karl Eichwalder <ke@gnu.franken.de> wrote:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> 
> > I wonder what do DTP and word processing programs do?  I guess if you
> > copy an italic word from one place to another it stays italic.
> 
> Yes and that's plain wrong--as a user I sufferd by this behavior.  If
> you copy a word from a (bold) title line you don't want to stay the
> word bold within your running text.
> 
> Only hackers believe that that's a feature.

I think non-hackers perceive things in WYSIWYG way, meaning if they
copy bold test they expect to paste bold text as well.  Only hackers
perceive text as data structure consisting of two parts, essential
character code portion and optional property (attribute) portion.

-Tak

Re: Question about copy-region-as-kill

[Andreas Schwab]

John Wiegley <johnw@gnu.org> writes:

|> >>>>> On Sat Apr  6, Eli writes:
|> 
|> > If most uses of text yanking want this rule, I think it makes sense
|> > to have it globally enabled.  Lisp programs which don't want that
|> > can always remove the properties before inserting the text.
|> 
|> How can I control the behavior of C-y?

You can write a wrapper function that removes the text properties
after calling yank.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Question about copy-region-as-kill

[Richard Stallman]

Text properties are part of the text.  Aside from special
cases there is no reason not to copy them.

Re: Question about copy-region-as-kill

[John Wiegley]

>>>>> On Sat Apr  6, RMS writes:

> Text properties are part of the text.  Aside from special cases
> there is no reason not to copy them.

Yet there DO exist reasons to avoid doing so, which at present force
people to resort to overlays.  I think there is sufficient evidence to
show that not copying text properties in certain buffers is a good
thing.

We're talking about such a small change here (see below).  I can't
believe there is a valid philosophical reason to _deny_ such
configurability, forcing an entirely different paradigm (overlays)
just to avoid the copy.

And whether these are stripped at kill or yank, I don't care.  I just
don't want read-only copied around when I kill text from Eshell, and
then yank it into an e-mail message!

John

----------------------------------------------------------------------

(defvar copy-properties-on-kill t)
(make-variable-buffer-local 'copy-properties-on-kill))

(defun copy-region-as-kill (beg end)
  "Save the region as if killed, but don't kill it.
In Transient Mark mode, deactivate the mark.
If `interprogram-cut-function' is non-nil, also save the text for a window
system cut and paste."
  (interactive "r")
  (let ((str (if copy-properties-on-kill
                 (buffer-substring beg end)
               (buffer-substring-no-properties beg end))))
    (if (eq last-command 'kill-region)
        (kill-append str (< end beg))
      (kill-new str)))
  (if transient-mark-mode
      (setq deactivate-mark t))
  nil)

Re: Question about copy-region-as-kill

[Alex Schroeder]

John Wiegley <johnw@gnu.org> writes:

> And whether these are stripped at kill or yank, I don't care.  I just
> don't want read-only copied around when I kill text from Eshell, and
> then yank it into an e-mail message!

Right.  Another example: When you use Colin's ibuffer.el and copy some
text from there (such as the file name of a buffer), it will have a
local keymap with totally weird mappings (eg. for RET and other common
keys) and it not entirely obvious how to get rid of them.

Alex.
-- 
http://www.emacswiki.org/

Re: Question about copy-region-as-kill

[Colin Walters]

On Sat, 2002-04-06 at 18:03, Alex Schroeder wrote:
> John Wiegley <johnw@gnu.org> writes:
> 
> > And whether these are stripped at kill or yank, I don't care.  I just
> > don't want read-only copied around when I kill text from Eshell, and
> > then yank it into an e-mail message!
> 
> Right.  Another example: When you use Colin's ibuffer.el and copy some
> text from there (such as the file name of a buffer), it will have a
> local keymap with totally weird mappings (eg. for RET and other common
> keys) and it not entirely obvious how to get rid of them.

Yes.  Richard and I discussed this at length in private email.  My
feelings on the subject are that the separation of overlays and text
properties doesn't make sense.  I *always* find myself wanting a
text-properties like API, but just sometimes do I want to make the
properties specific to the buffer.  For example, I very commonly attach
a property to text, using `propertize', and do things like search
forward in a buffer for the next piece of text which has a specific
property (e.g. `next-single-property-change').  I have *never* wanted to
know things like where all the "overlays" (i.e. regions of text with
buffer-specific properties) in the buffer are (e.g. `overlay-lists'), or
where the next overlay is (e.g. `next-overlay-change').  

In the interim, I will change ibuffer to use overlays for some
properties.  But for what it's worth, I think we should move towards an
XEmacs-style "extent" mechanism.

[ Richard, do you mind if I make our discussion available? ] 

Re: Question about copy-region-as-kill

[Miles Bader]

Colin Walters <walters@verbum.org> writes:
> In the interim, I will change ibuffer to use overlays for some
> properties.  But for what it's worth, I think we should move towards an
> XEmacs-style "extent" mechanism.

I thought `extent's were more like overlays, except optionally
persistent.  No?

In any case, perhaps you're right that text-properties should be
optionally buffer-specific, but that doesn't mean it's the proper thing
to get rid of the distinction between text-properties and overlays.

Overlays are distinct _objects_ that can be manipulated as such, and
lend their properties to the underlying buffer they're in, whereas
text-properties are not independent of the text at all.

These very different interfaces are both useful in different circumstances.

-Miles

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal

Re: Question about copy-region-as-kill

[John Wiegley]

>>>>> On Sat Apr  6, Miles writes:

> In any case, perhaps you're right that text-properties should be
> optionally buffer-specific, but that doesn't mean it's the proper
> thing to get rid of the distinction between text-properties and
> overlays.

> [...]

> These very different interfaces are both useful in different
> circumstances.

I agree.  I think overlays have their place; for example they allow
specialized font properties to be used in conjunction with font-lock,
like highlighting certain terms temporarily.  These overlays can then
all be deleted in one go, without having to search the text.

It's the use of overlays to avoid copying properties that seems
excessive, not overlays themselves.  In my opinion.  :)

John

Re: Question about copy-region-as-kill

[Colin Walters]

On Sat, 2002-04-06 at 21:53, John Wiegley wrote:
> I agree.  I think overlays have their place; for example they allow
> specialized font properties to be used in conjunction with font-lock,
> like highlighting certain terms temporarily.  These overlays can then
> all be deleted in one go, without having to search the text.

You mean like changing the face of some text temporarily, and then just
going through the buffer and deleting all the overlays to remove that
face?

This approach fails when you use overlays for any other purpose in the
same buffer; you then can't just delete all the overlays.

If we had extents, the right way to solve that problem, in my opinion,
would be to add another extent with a higher priority face, and another
property like 'temporary t.  Then, you could search for all extents with
a 'temporary property, and delete them.

Re: Question about copy-region-as-kill

[Miles Bader]

Colin Walters <walters@verbum.org> writes:
> If we had extents, the right way to solve that problem, in my opinion,
> would be to add another extent with a higher priority face, and another
> property like 'temporary t.  Then, you could search for all extents with
> a 'temporary property, and delete them.

Um, you can do exactly the same thing with overlays.

-Miles
-- 
Is it true that nothing can be known?  If so how do we know this?  -Woody Allen

Re: Question about copy-region-as-kill

[Colin Walters]

On Sat, 2002-04-06 at 23:58, Miles Bader wrote:
> Colin Walters <walters@verbum.org> writes:
> > If we had extents, the right way to solve that problem, in my opinion,
> > would be to add another extent with a higher priority face, and another
> > property like 'temporary t.  Then, you could search for all extents with
> > a 'temporary property, and delete them.
> 
> Um, you can do exactly the same thing with overlays.

I agree.  My point is that in this case overlays aren't being used for
their primary purpose: specificity to the current buffer.  

What I am trying to show is that the distinction between text properties
and overlays is arbitrary.  Or at least it certainly has been in my
experience.

Re: Question about copy-region-as-kill

[Miles Bader]

Colin Walters <walters@verbum.org> writes:
> My point is that in this case overlays aren't being used for
> their primary purpose: specificity to the current buffer.  

I don't think the concept of a `primary purpose' is all that useful,
since it's rather objective; the original reason may be different that
current thinking, and one person's view may differ from another's.

From my point of view, the _most_ important thing about overlays is that
they are distinct objects that are distinct from the text, and interact
with text properties and other overlays.

This gives them certain advantages:  an overlay can be quickly and
easily be moved or removed as a unit, possibly affecting many individual
properties; you can discover where a certain property came from, and
find other properties in the same overlay (even if they are otherwise
hidden by other overlays); you can have `layers' of properties that
interact.

However most of attributes are _disadvantages_ in many cases, where you
really just want to attach properties to the text; for such cases, text
properties are much more straightforward and easy to understand.

Not surprisingly, the particular advantages of overlays are most useful
for very dynamic properties (e.g. a highlighted region) that (surprise)
`overlay' the text.  [for this reason, it doesn't seem particularly
useful to have overlays be copyable like text properties; in my
experience overlays are often referred chiefly by an external reference
(e.g., a buffer-local variable).

> What I am trying to show is that the distinction between text
> properties and overlays is arbitrary.  Or at least it certainly has
> been in my experience.

I think you're quite wrong.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Question about copy-region-as-kill

[Colin Walters]

[ No need to CC me, by the way; I read this list ]

On Sun, 2002-04-07 at 01:53, Miles Bader wrote:

> I don't think the concept of a `primary purpose' is all that useful,
> since it's rather objective; the original reason may be different that
> current thinking, and one person's view may differ from another's.

Fair enough.

> >From my point of view, the _most_ important thing about overlays is that
> they are distinct objects that are distinct from the text, and interact
> with text properties and other overlays.

Indeed.  But extents provide these same advantages.  And it should not
be difficult to write a text properties API on top of an extents
mechanism.  So extents give you the best of all possible worlds, AFAICS.

Since I have the feeling that we are at this point arguing by repeated
assertion, let me paste here the description of the problem I ran into
using overlays for ibuffer, when RMS originally asked me why I thought
overlays had a poor interface:

> [ RMS asks why the overlay interface is bad ]

I don't like it because it forces me to use a completely different API
depending on whether or not I want the properties to be specific to the
buffer or not, despite the fact that I want the properties to actually
be associated with the text, not a specific region of the buffer.

As an example, when you define an ibuffer column, you can optionally
specify properties along with the text.  For example:

(define-ibuffer-column mode (:inline t
                             :props
                             ('mouse-face 'highlight
                              'keymap ibuffer-mode-name-map
                              'help-echo "mouse-2: filter by this mode"))
  (format "%s" mode-name))

This macroexpands to code that does:

(propertize (format "%s" mode-name) 'mouse-face 'highlight ...)

And then the ibuffer display function calls that bit of code, which
simply inserts the text, and it will have those associated properties. 
However, I *do* want those properties to be specific to the ibuffer
buffer!

To achieve both effects, I could make the code macroexpand to something
like

(list (format "%s" mode-name) '(mouse-face highlight ...))

And then the ibuffer display algorithm could save the value of point,
insert the text, make an overlay between the old value of point, and
finally put the properties on that overlay.  But that's pretty ugly. 
And ugly code leads me to conclude that I have the wrong approach.

Re: Question about copy-region-as-kill

[Alex Schroeder]

Colin Walters <walters@verbum.org> writes:

> And it should not be difficult to write a text properties API on top
> of an extents mechanism.

Obviously, because XEmacs continues to have a text-properties
interface to extents as well.  Unfortunately it differs subtly from
Emacs, but for many purposes it is similar enough.

Alex.
-- 
http://www.emacswiki.org/

Re: Question about copy-region-as-kill

[Miles Bader]

Colin Walters <walters@verbum.org> writes:
> Indeed.  But extents provide these same advantages.  And it should not
> be difficult to write a text properties API on top of an extents
> mechanism.

What I'm arguing for is to keep the current interfaces, because I think
they're both useful.  Whether or not they use the same underlying
mechanism is an implementation detail (about which others are more
knowledgable than I).

> So extents give you the best of all possible worlds, AFAICS.

We've already got an implementation that provides both; why change (but
see below)?

> Since I have the feeling that we are at this point arguing by repeated
> assertion, let me paste here the description of the problem I ran into
> using overlays for ibuffer, when RMS originally asked me why I thought
> overlays had a poor interface:

From your description, it sounds like you would be happy if [certain]
text-properties could be optionally suppressed from being copied by a
user; true?

I think that would be a useful extension to text-properties.

What I'm not sure of why you seem to have come to the conclusion that a
whole-sale reworking of the way text-properties and overlays work is
required.

Cheers,

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Question about copy-region-as-kill

[Colin Walters]

On Sun, 2002-04-07 at 08:20, Miles Bader wrote:

> What I'm arguing for is to keep the current interfaces, because I think
> they're both useful.  Whether or not they use the same underlying
> mechanism is an implementation detail (about which others are more
> knowledgable than I).

No, it's not just an implementation detail!  With the current text
properties/overlays separation, it is going to be a big pain to change
ibuffer to use overlays.  Maybe there is a better way to do it, but I
really don't see one (if someone does, please speak up!).  And it will
certainly be slower, as you noted in a different thread.  Not only that,
but it will generate more garbage: I will have to cons up at least one
cell for each string returned, plus bind lots of variables, *and* add
properties to the overlay one at a time.

If we had extents like mechanism as the underlying implementation of
both text properties and overlays, then I could fall back to just using
the raw extents interface to solve my problem.

> We've already got an implementation that provides both; why change (but
> see below)?

It provides both, as totally separate things.  I want to be able to pick
and choose from the features of each.

> >From your description, it sounds like you would be happy if [certain]
> text-properties could be optionally suppressed from being copied by a
> user; true?

That would solve this particular problem, yes. 

> What I'm not sure of why you seem to have come to the conclusion that a
> whole-sale reworking of the way text-properties and overlays work is
> required.

I guess the only thing I can say to this is that extents make a whole
lot more sense to me.  I agree with you that text properties and
overlays cover the majority of cases, but I think there is something
more fundamental lying behind both of them.

Re: Question about copy-region-as-kill

[Miles Bader]

Colin Walters <walters@verbum.org> writes:
> > Whether or not they use the same underlying
> > mechanism is an implementation detail (about which others are more
> > knowledgable than I).
> 
> No, it's not just an implementation detail!  With the current text
> properties/overlays separation, it is going to be a big pain to change
> ibuffer to use overlays.

I am claiming that text-properties and overlays are desirable
_interfaces_ to certain bits of functionality.  If you `change ibuffer
to use overlays' you're changing which _interface_ you use.  This
interface change wouldn't be any easier if text-properties were
implemented in terms of some sort of super-overlay.

What you _really_ seem want (though you never seem to come right out and
say it; or at least I missed it) is to be able to have buffer-specific
text-properties without changing the interface you use.  That is, to
extend the functionality of text-properties to include something that
overlays do.  I happen to think this would be a great change to
text-properties -- but that doesn't mean that the existing
implementations are fatally flawed!  Maybe they are, but this isn't the
evidence that shows that.

> Maybe there is a better way to do it, but I really don't see one (if
> someone does, please speak up!).  And it will certainly be slower, as
> you noted in a different thread.  Not only that, but it will generate
> more garbage: I will have to cons up at least one cell for each string
> returned, plus bind lots of variables, *and* add properties to the
> overlay one at a time.

I think the right answer is to extend text-properties so that you can
control which ones are copied out of a buffer.  Note that this solution
has _none_ of the drawbacks you list above.  [well, I think, anyway,
since some of them were a bit vague]

> If we had extents like mechanism as the underlying implementation of
> both text properties and overlays, then I could fall back to just using
> the raw extents interface to solve my problem.

Since the `raw extents' interface is (I think!) overlay-like, it
sounds like you'd have all the same pain, actually.

> > We've already got an implementation that provides both; why change (but
> > see below)?
> 
> It provides both, as totally separate things.  I want to be able to pick
> and choose from the features of each.

Please be more specific.  One reason why I don't think having two
separate implementations is bad, is that I don't think the separation is
as arbitrary as you do.

So:

If there are text-property features that you think overlays should
have, state them, and give some practical justification why they would
be good.

If there are overlay features that you think text-properties should
have, state them, and give practical justification why they would
be good.

You've already given example of the latter -- you want buffer-specific
text properties.  Now, as it happens this particular feature would be
pretty trivial to implement using the existing text-property
implementation.

However, if there's a long list of such (well justified!) features, then
maybe you're right, and a merged implementation would be better.  There
are a lot of disadvantages to such a merged implementation, so there
has to be a lot of justification too.

> > From your description, it sounds like you would be happy if [certain]
> > text-properties could be optionally suppressed from being copied by a
> > user; true?
> 
> That would solve this particular problem, yes. 

Good.

> I guess the only thing I can say to this is that extents make a whole
> lot more sense to me.  I agree with you that text properties and
> overlays cover the majority of cases, but I think there is something
> more fundamental lying behind both of them.

I've been very happy with TPs and overlays -- except for the issue of
unwanted copying of text properties.  In previous discussions about
how to handle that problem, the main stumbling block was what policy to
use to copy, and a merged implementation wouldn't help that at all.

Cheers,

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Question about copy-region-as-kill

[Colin Walters]

On Mon, 2002-04-08 at 02:18, Miles Bader wrote:

> I am claiming that text-properties and overlays are desirable
> _interfaces_ to certain bits of functionality.  If you `change ibuffer
> to use overlays' you're changing which _interface_ you use.  This
> interface change wouldn't be any easier if text-properties were
> implemented in terms of some sort of super-overlay.

If text properties were implemented in terms of a super-overlay (i.e.
extent), then I could manually use however they were implemented to
achieve "text properties" which are specific to a buffer.  In other
words, presumably text properties would be implemented entirely in Lisp
over extents, so I could just modify that code.

Presumably though, we would already have library code that does this.

> What you _really_ seem want (though you never seem to come right out and
> say it; or at least I missed it) is to be able to have buffer-specific
> text-properties without changing the interface you use.  

In this specific case, yes.  You are right that I am arguing for two
separate things.

1) buffer-specific text properties at the very minimum
2) the ability to fall back to a more general, and more powerful
interface to properties and text; i.e. something like XEmacs' extents. 
This would give the Lisp-level Emacs programmer a lot more freedom and
power.

> If there are text-property features that you think overlays should
> have, state them, and give some practical justification why they would
> be good.

I think an "overlay" should be able to optionally be associated with
text, or at least attempt to follow it around.  Like the XEmacs
duplicable property.  We'd like this for the case where an "object-type"
interface would be good, but we *do* want the properties to conceptually
be associated with the text.

> If there are overlay features that you think text-properties should
> have, state them, and give practical justification why they would
> be good.

I think text properties should optionally be able to be specific to the
current buffer.  This would solve the ibuffer problem.

> However, if there's a long list of such (well justified!) features, then
> maybe you're right, and a merged implementation would be better.  There
> are a lot of disadvantages to such a merged implementation, so there
> has to be a lot of justification too.

I'm curious what the disadvantages you see are.  I don't claim to be an
expert in this area, so there certainly exists the possibility that
there are major disadvantages.  But the existence of the XEmacs extent
mechanism seems to argue strongly that even if such disadvantages exist,
they are outweighed by the advantages.

Re: Question about copy-region-as-kill

[Richard Stallman]

You seem to want major changes in the Emacs facilities for text
properties and overlays.  For many reasons, we will not make such
major or fundamental changes.  It isn't practical and they would have
big disadvantages.  Even to discuss this indepth would take time
that I cannot afford to spend.

If you propose specific small changes, they could perhaps be feasible
to make.

Re: Question about copy-region-as-kill

[Richard Stallman]

    If we had extents like mechanism as the underlying implementation of
    both text properties and overlays, then I could fall back to just using
    the raw extents interface to solve my problem.

That would be indistinguishable in practice form using overlays for
everything.  It would not be terribly hard to do this, but if indeed
overlays are slower, then this will make everything that now uses text
properties slower.

Are overlays actually slower, for something like font-lock?
I don't know.

      I agree with you that text properties and
    overlays cover the majority of cases, but I think there is something
    more fundamental lying behind both of them.

I don't think overlays (whether you call them "extents" or not)
are lying behind text properties.

Re: Question about copy-region-as-kill

[Colin Walters]

On Tue, 2002-04-09 at 08:07, Richard Stallman wrote:
>     If we had extents like mechanism as the underlying implementation of
>     both text properties and overlays, then I could fall back to just using
>     the raw extents interface to solve my problem.
> 
> That would be indistinguishable in practice form using overlays for
> everything.  It would not be terribly hard to do this, but if indeed
> overlays are slower, then this will make everything that now uses text
> properties slower.

This seems to me to be an implementation issue.  Redisplay is far
outside my area of knowledge, but since XEmacs seems to be "fast enough"
at font-locking, I think this suggests that it doesn't have to be slow.

> Are overlays actually slower, for something like font-lock?
> I don't know.

My subjective feeling is that Emacs overlays are currently substantially
slower than Emacs text properties, yes.  But it would be hard to make an
objective comparison without rewriting font-lock entirely...

> I don't think overlays (whether you call them "extents" or not)
> are lying behind text properties.

The XEmacs manual claims that their text properties are implemented in
terms of extents:

"Text properties are an alternative interface to extents (*note
Extents::), and are built on top of them."

I don't want to actually look at the source, because I would like to
help in the implementation of extents (or the extension of overlays,
however you want to look at it) for Emacs.

Re: Question about copy-region-as-kill

[John Wiegley]

>>>>> On Sat Apr  6, Colin writes:

> You mean like changing the face of some text temporarily, and then
> just going through the buffer and deleting all the overlays to
> remove that face?

> This approach fails when you use overlays for any other purpose in
> the same buffer; you then can't just delete all the overlays.

Ah, not so.  You see, one's mode can internally maintain lists of the
overlays it uses for different purposes.  This is part of the beauty
of having them returned to the caller as created objects.  You then
just rip through the list, deleting the kind of overlay you wish.

John

Re: Question about copy-region-as-kill

[Colin Walters]

On Sun, 2002-04-07 at 01:36, John Wiegley wrote:

> Ah, not so.  You see, one's mode can internally maintain lists of the
> overlays it uses for different purposes.  This is part of the beauty
> of having them returned to the caller as created objects.  You then
> just rip through the list, deleting the kind of overlay you wish.

True, but if we had extents, then *both* approaches could be used.  If
it was inconvenient to record a list of your extents, then you could
just search for them by property.  I've often found recording lists to
be inconvenient in the modes I've written; but I can see how it would be
a very good approach to use in other situations.

Note that Emacs already has `next-single-char-property-change'; I
believe the very existence of this function supports my argument.

Re: Question about copy-region-as-kill

[Richard Stallman]

    If we had extents, the right way to solve that problem, in my opinion,
    would be to add another extent with a higher priority face, and another
    property like 'temporary t.  Then, you could search for all extents with
    a 'temporary property, and delete them.

You can do this now, with overlays.  Overlays are a lot like extents.

    Ok, I looked at the XEmacs manual a bit, and yes, that appears to be the
    case.  Note that they have built a text properties/overlays type API on
    top of their extent mechanism.

We can do that, too.  In fact, we partly already have.
I was trying to convince you to help do more of it.

    I guess all I can do is assert that an XEmacs-style extent mechanism
    would make a lot more sense to me, personally.

The advantages you see are not real advantages because they are not
really differences.  If you like the extent facility it makes no sense
for you to dislike the extremely similar overlay facility.

Re: Question about copy-region-as-kill

[Colin Walters]

On Sun, 2002-04-07 at 19:42, Richard Stallman wrote:
>     If we had extents, the right way to solve that problem, in my opinion,
>     would be to add another extent with a higher priority face, and another
>     property like 'temporary t.  Then, you could search for all extents with
>     a 'temporary property, and delete them.
> 
> You can do this now, with overlays.  Overlays are a lot like extents.

Yes.  In fact, as far as I can see, overlays are only really missing one
major feature; what the XEmacs people call the "duplicable" property,
such that when text covered by an extent is copied and later inserted
into another buffer, a new extent with the same properties is created
covering the text.

> We can do that, too.  In fact, we partly already have.
> I was trying to convince you to help do more of it.

Yes, you mentioned insert-with-overlays.  I'm going to work on it after
finishing update-game-score.

> The advantages you see are not real advantages because they are not
> really differences.  If you like the extent facility it makes no sense
> for you to dislike the extremely similar overlay facility.

Extremely similar, except for that all-important duplicable property,
which would solve my ibuffer problem in a clean way.

Re: Question about copy-region-as-kill

[Richard Stallman]

    > The advantages you see are not real advantages because they are not
    > really differences.  If you like the extent facility it makes no sense
    > for you to dislike the extremely similar overlay facility.

    Extremely similar, except for that all-important duplicable property,
    which would solve my ibuffer problem in a clean way.

Would you please be precise?

Re: Question about copy-region-as-kill

[Colin Walters]

On Tue, 2002-04-09 at 08:07, Richard Stallman wrote:
>     > The advantages you see are not real advantages because they are not
>     > really differences.  If you like the extent facility it makes no sense
>     > for you to dislike the extremely similar overlay facility.
> 
>     Extremely similar, except for that all-important duplicable property,
>     which would solve my ibuffer problem in a clean way.
> 
> Would you please be precise?

I answered this in my reply to Miles.  Basically, since text properties
would be implemented in Lisp over extents, I could use that code to
build my own text properties which are specific to a buffer.  More than
likely though I wouldn't have even to do that; I think more people would
want to use such an API, so it would already be part of Emacs.

Re: Question about copy-region-as-kill

[Colin Walters]

On Sat, 2002-04-06 at 19:56, Miles Bader wrote:
> Colin Walters <walters@verbum.org> writes:
> > In the interim, I will change ibuffer to use overlays for some
> > properties.  But for what it's worth, I think we should move towards an
> > XEmacs-style "extent" mechanism.
> 
> I thought `extent's were more like overlays, except optionally
> persistent.  No?

Ok, I looked at the XEmacs manual a bit, and yes, that appears to be the
case.  Note that they have built a text properties/overlays type API on
top of their extent mechanism.

> In any case, perhaps you're right that text-properties should be
> optionally buffer-specific, but that doesn't mean it's the proper thing
> to get rid of the distinction between text-properties and overlays.
> 
> Overlays are distinct _objects_ that can be manipulated as such, and
> lend their properties to the underlying buffer they're in, whereas
> text-properties are not independent of the text at all.
> 
> These very different interfaces are both useful in different circumstances.

That's what I thought at first, too...but I've personally *never*
encountered a situation in which I've wanted to use the overlay API.

Re: Question about copy-region-as-kill

[Miles Bader]

Colin Walters <walters@verbum.org> writes:
> That's what I thought at first, too...but I've personally *never*
> encountered a situation in which I've wanted to use the overlay API.

What can I say?  I have encountered many such situations.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: Question about copy-region-as-kill

[Colin Walters]

On Sat, 2002-04-06 at 23:58, Miles Bader wrote:
> Colin Walters <walters@verbum.org> writes:
> > That's what I thought at first, too...but I've personally *never*
> > encountered a situation in which I've wanted to use the overlay API.
> 
> What can I say?  I have encountered many such situations.

I admit I think that some must exist, or else this issue would have come
up a long time ago.  Anyways, this is mainly orthogonal to my original
point, which is that I've very often wanted buffer-specific text
properties.  And if those exist, I imagine there is a situation in which
someone would want to manipulate (non buffer-specific) text properties
as separate objects, like overlays.

I guess all I can do is assert that an XEmacs-style extent mechanism
would make a lot more sense to me, personally.

I explained the reasons behind my frustration with text properties and
overlays with respect to ibuffer in that discussion with Richard; if he
gives me permission to put it up somewhere, then maybe you could see
where I'm coming from.

Re: Question about copy-region-as-kill

[Kai Großjohann]

John Wiegley <johnw@gnu.org> writes:

> And whether these are stripped at kill or yank, I don't care.  I just
> don't want read-only copied around when I kill text from Eshell, and
> then yank it into an e-mail message!

Indeed.  This has annoyed me before.  Now you have convinced me that
sometimes it is a good idea to strip text properties.

Hm.

Sadly, it's not possible to use the prefix argument for yank to say
don't yank the text properties.  Hm.

kai
-- 
Silence is foo!

Re: Question about copy-region-as-kill

[Kai Großjohann]

John Wiegley <johnw@gnu.org> writes:

> Perhaps there should be a buffer-local-variable
> `copy-properties-on-kill'.  In the majority of cases, I think property
> copying is the wrong thing to do.

I think it's not clear whether properties should be removed when
killing or when yanking (if they are removed at all).

kai
-- 
Silence is foo!