Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Changes
|
Wishlist
PuTTY's handling of copy and paste has two related problems.
PuTTY insists on copying to the clipboard as soon as you select text, without waiting for any subsequent UI action meaning 'copy'.
That was a deliberate design decision early in development, because the original Windows PuTTY was primarily aimed at users who would prefer to be using Unix/X11 desktops but were forced to use Windows instead; I expected that such users would see the X-style copy/paste UI as a breath of fresh air and a nice reminder of home.
But these days, by no means all PuTTY users fall into that category. So people can find PuTTY's unusual copy/paste UI surprising, since it's unlike all the other applications they use; also, it can be outright inconvenient, because sometimes (depending on details of mouse setup) it can be annoyingly easy to select text in the PuTTY window by mistake, which wipes out the previous clipboard contents, which you might well have been about to use for something.
PuTTY assumes, on all platforms, that there is exactly one clipboard; it has just one copy operation, which writes to that clipboard, and one paste operation which reads from it.
But in modern X11-based desktop environments, this is a wrong
assumption. In principle, an X server supports an open-ended set of
'selections', each given an identifying name; in practice, there are
two in common use. One, called PRIMARY, is typically
accessed by the old-school X11 user interface that Windows PuTTY
mimics: just select some text, and middle-click to paste it elsewhere.
The other, CLIPBOARD, follows the more Windowsy UI
tradition of having explicit Copy and Paste commands in menus, or
pairs of keyboard shortcuts along the lines of ^C/^V or
Shift-Ins/Ctrl-Ins.
I have to suppose that the point of this system was to make both
old-school X users and migrants from Windows each feel at home, by
supporting each one's preferred UI without the other one confusing it.
But once you realise that the two UI mechanisms access different
clipboards, that can be useful in its own right, because you can
develop usage habits that make use of both of them at once – for
example, you can use the less easily
overwritten CLIPBOARD to store one piece of text, then
repeatedly use PRIMARY for a sequence of select-paste
operations, and finally use the other paste command to retrieve what
you left in CLIPBOARD.
Except that in Unix PuTTY, you can't, because it currently doesn't
support reading or writing CLIPBOARD at all.
Even one-clipboard systems have occasionally been known to mimic a double clipboard. The standard OS X Terminal application, for example, doesn't access the real inter-application system clipboard except by explicit user action (Command-{C,V}, or menu items) – but nonetheless it also supports a select-and-middle-click mode of operation, which as far as I can tell uses a 'clipboard' which exists solely in the imagination of Terminal itself and can't communicate with any other application.
At a technical level, all of this is easily enough fixed.
At present, text selected in the terminal window is passed immediately
to a frontend write_clip() function, which need not
retain a copy of the text at all – on Windows, it just shoves it
straight into the system clipboard and forgets about it. (On X11, it
does have to retain a copy, because the selection system requires the
selection owner to physically send the data to each application
requesting a paste.)
So it wouldn't be hard at all to arrange a bit more flexibility in the code, whereby the act of selecting text caused it to be copied into an internal buffer to be remembered (and optionally also written out to some system clipboard or other), and then a subsequent UI action could be made to copy the text again from that buffer into a different clipboard.
The only question, at the code-structure level, is to what extent this
can sensibly be centralised into the cross-platform code. I think
probably the ideal is that each front end would define a set of
numeric ids indicating distinct system clipboards; the
existing write_clip() and request_paste()
functions would grow an extra id argument indicating which clipboard
was being accessed; and terminal.c would take care of
stashing the selected text in a buffer, and provide an extra function
'now please copy the last-selected text to a new clipboard', which
front ends could call in response to explicit Copy UI actions, and
which would respond by passing that buffer back
to write_clip() with a different id.
(There's one other small thing, which is that front ends currently
call term_deselect() to visually unmark the selection,
when they detect that they're no longer the clipboard owner. Probably
the right answer would be to instead notify the terminal driver that
it had lost ownership of a clipboard, along the lines
of term_lost_clipboard(id); then the terminal driver
could decide for itself what it wanted to do to the display in
response.)
So the reason this isn't a trivial job is the user interface.
On single-clipboard systems, there are several things you might plausibly want to configure:
On X11, with its multiple system clipboards, things ought to
be nice and simple: you'd like to think that no configurability is
needed at all, because you just have selection and middle-click write
and read PRIMARY, and explicit keyboard or menu
copy/paste commands talk to CLIPBOARD, and then you're
just like any other modern X app and that's the end of it. Except that
there are two remaining issues:
PRIMARY, and changing that would
undoubtedly break someone's
workflow.
SECONDARY) has been used in history. So as long as we're
reworking this area anyway, it would be nice to arrange that
there's some way to access extra clipboards.
So perhaps it would be better to come up with a fully general
interface for configuring this whole area, so that you could
independently configure which clipboard was accessed by
various pairs of copy-and-paste keyboard actions
({Shift,Ctrl}-Ins, gnome-terminal style Ctrl-Shift-{C,V},
Command-{C,V} on OS X), which one (if any) PuTTY would auto-copy to on
selection, and which one(s) there were menu items to talk to. The set
of available clipboards could be configured by a combo box on X11 (so
you could manually enter the name of a nonstandard clipboard if you
had a use for one) and by a drop-down list elsewhere; and if we provided a
Terminal.app style imaginary internal clipboard, then
that could just appear in the same list.
That highly general system would let everybody have what they want – except for the people who wanted to configure one of the two obvious options with a single button press, and not have to deal with a piece of GUI looking like the instrument panel of a major airliner.
So I'd prefer a configuration UI which makes simple things simple and difficult things possible, and I haven't thought one up yet!
2017-12-17: now done, with a medium-level compromise UI, not too complicated but not 100% fully general either. But it should support most things that anyone sensible will want :-)