Re: [PATCH] C-y and M-y behavior
On 11 Apr 2002 at 15:27:27 +0900, "Stephen J. Turnbull"
<stephen(a)xemacs.org> wrote:
I'm going to put this into 21.4 because it's simple and works
(and we
just got a complaint on xemacs-beta, I think it was), unless somebody
finds a problem with it that I can't see. But I question whether it's
the right way to handle it for 21.5.
For one thing, isn't this going to add more icky slowness to the life
of people who like to cut and paste megabytes with their mouse?
You know, it seemed like a good idea last night when I was suffering
from severe sleep deprivation. In the cold light of morning, I see
several problems with it. When using own-clipboard and get-clipboard,
the problem you mention can be solved by noting that, when no other
application has changed the clipboard, the string returned by
get-clipboard is EQ to the one last passed to own-clipboard.
Also, I thought I needed to introduce a new variable to correctly handle
the case where the same string is cut, copied, or killed multiple times.
However, the patch I submitted has the property that
last-interprogram-cut is always EQ to (car kill-ring), so we might as
well use that and avoid a new variable.
The killing blow is that this is entirely the wrong approach anyhow.
The problem is really in own-clipboard/get-clipboard. Look at this
excerpt from the docstring for interprogram-paste-function:
Note that the function should return a string only if a program other
than Emacs has provided a string for pasting; if Emacs provided the
most recent string, the function should return nil. If it is
difficult to tell whether Emacs or some other program provided the
current string, it is probably good enough to return nil if the string
is equal (according to `string=') to the last text Emacs provided.
There's the problem; get-clipboard is returning a string when it should
be returning nil. But now it gets weird. That function is defined in
select.el. It doesn't really have access to anything that would tell if
it XEmacs owns the selection or not, so it looks like we should peek
into get-selection-internal, which is defined in select.c. It looks to
me like that function ought to work something like this:
If there is something in Vselection_alist that matches
return nil
Else
return whatever the appropriate device wants to give us
But look how hard that function works to find something on
Vselection_alist to return! I don't want to suggest throwing all that
code out without understanding why it is there. Can anybody shed some
light on this?
--
Jerry James
james(a)xemacs.org