Bulgarian mirror 10 Gbps

PuTTY wish clipboard-generality

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.

No way to separate select from copy operation

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.

No support for multiple clipboards/selections

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.

Technical discussion

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.)

User interface and generality

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:

• Automatic copy on selection: on/off.
• Middle-click paste: on/off. (Or perhaps not – it's just a guess that people who don't want X-like selection might actively prefer to get rid of middle-click paste, if for some reason they find it a bit hair-trigger.)
• Imaginary second clipboard, in OS X Terminal style: on/off.

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:

• Legacy UI: in current X PuTTY, Shift-Ins pastes from PRIMARY, and changing that would undoubtedly break someone's workflow.
• Further clipboards. As mentioned above, X in principle supports an open-ended set of selections, and at least one (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 :-)