Graphical Kill node in Emacs manual

Graphical Kill node in Emacs manual

[Drew Adams]

Perhaps this Emacs-manual node should be split, or its contents moved
elsewhere (since it is small, and it would be smaller still, if split).

Currently, these two very different topics are presented in this node:

1. Relation between inter-application clipboard and Emacs kill ring. Yanking
between applications.

2. Delete Selection mode.

I think #1 deserves more explanation, if I understand it correctly.

The clipboard isn't even mentioned here. I think the clipboard is important
to understanding yank interaction with other apps (I don't claim to
understand that well, so I might be wrong here). If this does not need more
explanation, then perhaps this paragraph could simply be merged with its
parent node. If this is related to the clipboard, as I suspect, then perhaps
it could be merged with node Clipboard somehow.

Also, node Clipboard is in the Frames section of the manual (presumably
because of its relation to X Window), not the Killing section, and there is
no cross reference between the two. Surely, the clipboard is related somehow
to the kill ring, at least conceptually?

#2 should be separated from #1, IMO. People will not find #2 by trying to go
to node `Graphical Kill', and #2 has only a limited relation to #1 - it
seems added here only as an afterthought.

How about creating a node that describes PC Selection mode and Delete
Selection mode, and relates them to Transient Mark mode? IIUC, PC Selection
mode uses Delete Selection mode (more or less), which uses Transient Mark
mode. Users often ask about this sort of thing, and the answer usually
informs them about all three levels, so they can decide what they want:

a. Transient Mark mode to highlight the active region.

b. Delete Selection mode to do (a) plus type-to-replace behavior.

c. PC Selection mode to do (b) plus provide PC key bindings.

[BTW - To me, (b) is a great way to use Emacs, and I would never consider
using (c), PC bindings. I don't think of Delete Selection mode as emulating
another editor; I think of it as the right way to use Emacs ;-). Too often,
I think, D-S mode gets relegated to the margin of "emulation" modes, along
with vi stuff and MS Windows stuff. I suspect more users would use it if
they knew what it was. Personally, I think it should be the Emacs default
behavior.]

Also, in any explanation of Delete Selection mode, we should mention that
this involves killing, not deleting, in spite of the name. That is, you can
yank back the "deleted" text. This is not obvious, IMO. A better name for
this feature would be "Type-to-Replace" mode or "Overwrite-Region" mode, but
it's too late for that now.

Perhaps someone more knowledgeable than I can make better suggestions here,
but I think something should be done to better present the relations
between:

* the kill ring and the clipboard
* Delete Selection mode, PC Selection mode, and Transient Mark mode

If no change is made to this node, we should at least find a better name for
it than Graphical Kill. You can't even use `i' to find this node by looking
up `kill' or `clipboard' or `overwrite' (which is essentially what
type-to-replace is: overwriting the region). How someone would use `i' to
find this information on Delete Selection mode is beyond me, unless s?he
knew that it was called `delete-selection-mode'.

Re: Graphical Kill node in Emacs manual

[Slawomir Nowaczyk]

On Fri, 18 Aug 2006 09:48:06 -0700
Drew Adams <drew.adams@oracle.com> wrote:

I have no opinion on the rest of your email...

#> Also, in any explanation of Delete Selection mode, we should mention that
#> this involves killing, not deleting, in spite of the name. That is, you can
#> yank back the "deleted" text. This is not obvious, IMO.

This doesn't work for me... When I type, the selected region does get
deleted, as the mode name suggests, not killed.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

Numeric stability is probably not all that important when you're guessing.

RE: Graphical Kill node in Emacs manual

[Drew Adams]

    I have no opinion on the rest of your email...
    
    #> Also, in any explanation of Delete Selection mode, we should 
    #> mention that this involves killing, not deleting, in spite
    #> of the name.  That is, you can yank back the "deleted" text.
    #> This is not obvious, IMO.
    
    This doesn't work for me... When I type, the selected region does get
    deleted, as the mode name suggests, not killed.

Glad you checked this. You're right.

I was checking by selecting the region with the mouse, and I have `mouse-drag-copy-region' = t (the default value). So, in fact, it was the mouse drag that was copying to the kill ring. Sorry for the misinformation.

Re: Graphical Kill node in Emacs manual

[Richard Stallman]

The reason this does not mention the Clipboard is that it usually
doesn't involve use of the Clipboard.  The Clipboard is an optional
facility under X, and normally isn't used at all.

The Clipboard info is in the Frames chapter as part of the full info
on Emacs and selections.  That is not a 100% ideal place for it,
but I am not sure any other place is better.

Perhaps Graphical Kill should have an xref leading to that
whole part of the manual.

    #2 should be separated from #1, IMO. People will not find #2 by trying to go
    to node `Graphical Kill', and #2 has only a limited relation to #1 - it
    seems added here only as an afterthought.

A node just describing Delete Selection mode would be undesirably short.

    How about creating a node that describes PC Selection mode and Delete
    Selection mode, and relates them to Transient Mark mode?

It might be a good idea.

RE: Graphical Kill node in Emacs manual

[Drew Adams]

    The reason this does not mention the Clipboard is that it usually
    doesn't involve use of the Clipboard.  The Clipboard is an optional
    facility under X, and normally isn't used at all.

Perhaps I misspoke - I'm unclear on when the X clipboard is used to
copy+paste between applications (the subject of this node) and when it is
not used.

I really meant the _notion_ of a clipboard, that is, what is called the
clipboard in many apps, which in Emacs is closest to the kill ring itself.

My point about the "clipboard" here was really that this short node combines
two things: mention of 1) killing and yanking between apps, and 2)
delete-selection mode. The second paragraph (#2) does not need the first
(#1) to understand it, and vice versa - the two subjects are relatively
independent. If this node is intended to be about #1 (based on the title),
then #2 is off-topic.

    The Clipboard info is in the Frames chapter as part of the full info
    on Emacs and selections.  That is not a 100% ideal place for it,
    but I am not sure any other place is better.

    Perhaps Graphical Kill should have an xref leading to that
    whole part of the manual.

Yes, if the Clipboard section helps understand the stuff on inter-app
yanking, then an xref would help. As I say, I myself am not clear when the
Emacs (X) clipboard is actually used. I can copy and paste between apps, but
I have no idea if I'm using the X clipboard (I'm using MS Windows).

        #2 should be separated from #1, IMO. People will not find
        #2 by trying to go to node `Graphical Kill', and #2 has
        only a limited relation to #1 - it
        seems added here only as an afterthought.

    A node just describing Delete Selection mode would be undesirably short.

Likewise, a node saying only what is said in paragraph #1. That's why I
suggested merging it with its parent node.

        How about creating a node that describes PC Selection mode
        and Delete Selection mode, and relates them to Transient Mark mode?

    It might be a good idea.

RE: Graphical Kill node in Emacs manual

[Stuart D. Herring]

> Perhaps I misspoke - I'm unclear on when the X clipboard is used to
> copy+paste between applications (the subject of this node) and when it is
> not used.
> [...]
> Yes, if the Clipboard section helps understand the stuff on inter-app
> yanking, then an xref would help. As I say, I myself am not clear when the
> Emacs (X) clipboard is actually used. I can copy and paste between apps,
> but
> I have no idea if I'm using the X clipboard (I'm using MS Windows).

Just so everyone is up-to-date:
Any application can obviously store user data and provide it for reuse. 
Call this the "reuse area".  Emacs calls it the kill ring.  Windowing
environments often provide a common communication mechanism for text (and
sometimes other objects) to be transferred between windows (and even
between processes).

On Windows, this is implemented with a memory buffer, called the Windows
clipboard (or just "the clipboard").  Any application can write or read
this as it wishes; typically the writing is associated with "Cut" (Emacs:
kill) or "Copy" actions, and the reading with "Paste" actions (called
yanking in Emacs).

On X, this concept is implemented somewhat differently.  There are a set
of tokens, called "selections" -- two of which are labelled "primary" and
"clipboard" -- that a process may possess.  Note that these are not
buffers and do not hold data.  Instead, when a process decides that the
user has copied something, it simply requests the token.  When another
process wants to use the copied data, it asks the X server for the text
associated with the token, and the X server in turn asks the owning
process.  That process can reply with whatever data it wants -- typically
"what the user copied", but it can even vary from request to request
without user action if the process chooses -- and that data is passed by X
to the requester.  Note that this has the unfortunate side effect that
when a process dies, its "clipboard data", if any, is lost.

Further confusion on X: there are also buffers (like Windows has) called
"cut buffers".  However, these are deprecated (or at least nearly so)
because they are inflexible, may have size limitations, and require data
communication between a client and the server whenever something is
copied, whether or not it is ever used.   (Remember that in X the client
and server may easily be on different continents.)

Yet more X confusion: on Mac under X, there is the Aqua clipboard (which
as far as I know is much like the Windows one) and then the complete set
of X mechanisms; the issue of synchronization between these two
environments is separate and typically outside of Emacs' control.

Finally, there is the question of whether and how processes synchronize
their reuse areas with the system buffers or tokens.  On Windows, this is
often a non-issue -- the only standard mechanism is a buffer, and the
process can write to it and forget that it even did so.  On X, it varies
between programs because (A) there are multiple tokens and buffers and (B)
using selections implies that the process must remember the text for an
indeterminate length of time -- possibly even after the text is no longer
otherwise "active" in the application.  For instance, a user copies some
text in a terminal program, but then executes a verbose command therein
which scrolls the copied text out of the scrollback.  Some programs will
forget the text (and hopefully inform the X server that they no longer
have anything to provide), while others will make a separate copy of the
text then or at the time of the copy command and keep it around until
something else is copied (whether in that application or another).

Emacs has its own complications because it wants its reuse area to be more
powerful than either of these standard clipboard mechanisms.  Emacs'
policy is to, after every kill, copy it to the Windows clipboard or store
it to an X cut buffer (if it's small) and advertise it as one or both of
the "primary" and "clipboard" X selections.  When text is to be yanked,
Emacs consults the Windows clipboard and/or the various X resources and
uses text from them if it's not text that Emacs itself put there.  If it
does so, that text is copied onto the kill ring as well as yanked. 
Otherwise, the kill ring (and the current position within it) is used as
usual.  There are a few options in term/x-win.el and w32-fns.el that
control some of the specifics of this, and the whole operation can be
disabled or rewritten via the `interprogram-cut-function' and
`interprogram-paste-function' variables.

I hope this helps people understand the scenarios involved with killing
and yanking a bit better.  As a final note, a couple of problems that have
been observed in this area:
1. Keyboard macros that use the kill ring will also end up using the
system transfer mechanisms.  This can be a bad thing if the user was
hoping to use them while letting a macro run "in the background".
2. Emacs' rules for picking good X selections to use and its management of
its own selections weren't perfect the last time I checked, but it's hard
to come up with an optimum set.  There may yet be real bugs, though.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: Graphical Kill node in Emacs manual

[Drew Adams]

This is very helpful. Thanks.

I'm not sure what this should mean for the Emacs doc, if anything.

Regarding the term "clipboard", here is another data point:

Its meaning as a buffer or other storage area (essentially, a variable - the
"reuse area" you mention), or as a set of these, predates MS Windows. It has
been used that way in applications such as Framemaker, for instance, since
long before MS Windows was born.

Though the kill ring has additional properties, it seems very close to the
notion of clipboard in both MS Windows and in applications such as
Framemaker (on whatever platform).

It sounds, IIUC, as if it is the X Window use of the term that is the most
exceptional (and most complex). When Emacs interfaces with X-Window, this
also complicates the explanation of the Emac kill ring, but otherwise, I'd
think that the explanation of the kill ring would be straightforward.

Do I understand this correctly? In most uses of the term "clipboard", it is
simply a memory location (or set of such), but in X Window, it is a dynamic
request to an app, which can return anything it wants. (And, there are other
such selections: primary, secondary...)

If this is the case, why not write the Emacs doc to refer to the term
"clipboard" in the widely understood sense, except when specifically
speaking about X Window (and point out this shift in terminology)? I think
it would help users, who are used to this simple notion of clipboard, to
mention that the kill ring is like a clipboard.

Do you, Davis, who seem to understand this well, think the doc could be made
clearer in this area? If so, could you suggest something?

Thanks again for the info. - Drew

    > Perhaps I misspoke - I'm unclear on when the X clipboard is used to
    > copy+paste between applications (the subject of this node)
    > and when it is not used.
    > [...]
    > Yes, if the Clipboard section helps understand the stuff on inter-app
    > yanking, then an xref would help. As I say, I myself am not
    > clear when the Emacs (X) clipboard is actually used. I can copy
    > and paste between apps, but I have no idea if I'm using the X
    > clipboard (I'm using MS Windows).

    Just so everyone is up-to-date:
    Any application can obviously store user data and provide it for reuse.
    Call this the "reuse area".  Emacs calls it the kill ring.  Windowing
    environments often provide a common communication mechanism for
    text (and sometimes other objects) to be transferred between windows
    (and even between processes).

    On Windows, this is implemented with a memory buffer, called the Windows
    clipboard (or just "the clipboard").  Any application can write or read
    this as it wishes; typically the writing is associated with
    "Cut" (Emacs: kill) or "Copy" actions, and the reading with "Paste"
    actions (called yanking in Emacs).

    On X, this concept is implemented somewhat differently.  There are a set
    of tokens, called "selections" -- two of which are labelled
    "primary" and
    "clipboard" -- that a process may possess.  Note that these are not
    buffers and do not hold data.  Instead, when a process decides that the
    user has copied something, it simply requests the token.  When another
    process wants to use the copied data, it asks the X server for the text
    associated with the token, and the X server in turn asks the owning
    process.  That process can reply with whatever data it wants --
    typically
    "what the user copied", but it can even vary from request to request
    without user action if the process chooses -- and that data is
    passed by X
    to the requester.  Note that this has the unfortunate side effect that
    when a process dies, its "clipboard data", if any, is lost.

    Further confusion on X: there are also buffers (like Windows has) called
    "cut buffers".  However, these are deprecated (or at least nearly so)
    because they are inflexible, may have size limitations, and require data
    communication between a client and the server whenever something is
    copied, whether or not it is ever used.   (Remember that in X the client
    and server may easily be on different continents.)

    Yet more X confusion: on Mac under X, there is the Aqua clipboard (which
    as far as I know is much like the Windows one) and then the complete set
    of X mechanisms; the issue of synchronization between these two
    environments is separate and typically outside of Emacs' control.

    Finally, there is the question of whether and how processes synchronize
    their reuse areas with the system buffers or tokens.  On
    Windows, this is
    often a non-issue -- the only standard mechanism is a buffer, and the
    process can write to it and forget that it even did so.  On X, it varies
    between programs because (A) there are multiple tokens and
    buffers and (B)
    using selections implies that the process must remember the text for an
    indeterminate length of time -- possibly even after the text is
    no longer
    otherwise "active" in the application.  For instance, a user copies some
    text in a terminal program, but then executes a verbose command therein
    which scrolls the copied text out of the scrollback.  Some programs will
    forget the text (and hopefully inform the X server that they no longer
    have anything to provide), while others will make a separate copy of the
    text then or at the time of the copy command and keep it around until
    something else is copied (whether in that application or another).

    Emacs has its own complications because it wants its reuse area
    to be more
    powerful than either of these standard clipboard mechanisms.  Emacs'
    policy is to, after every kill, copy it to the Windows
    clipboard or store
    it to an X cut buffer (if it's small) and advertise it as one or both of
    the "primary" and "clipboard" X selections.  When text is to be yanked,
    Emacs consults the Windows clipboard and/or the various X resources and
    uses text from them if it's not text that Emacs itself put there.  If it
    does so, that text is copied onto the kill ring as well as yanked.
    Otherwise, the kill ring (and the current position within it) is used as
    usual.  There are a few options in term/x-win.el and w32-fns.el that
    control some of the specifics of this, and the whole operation can be
    disabled or rewritten via the `interprogram-cut-function' and
    `interprogram-paste-function' variables.

    I hope this helps people understand the scenarios involved with killing
    and yanking a bit better.  As a final note, a couple of
    problems that have been observed in this area:
    1. Keyboard macros that use the kill ring will also end up using the
    system transfer mechanisms.  This can be a bad thing if the user was
    hoping to use them while letting a macro run "in the background".
    2. Emacs' rules for picking good X selections to use and its
    management of
    its own selections weren't perfect the last time I checked, but
    it's hard
    to come up with an optimum set.  There may yet be real bugs, though.

    Davis

Re: Graphical Kill node in Emacs manual

[Richard Stallman]

I did some reorganization of the Emacs manual nodes
for cut and paste.  Please take a look.