Re: X11 clipboard patch beginnings
- Neil Bird wrote:
> OK, well nobody had any comments on my earlier posting about the X11The code helps us to get this going, very good.
> clipboard, so I've made a little stab.
> Attached is a patch to ui.c (from within /src) that implements theAn alternative would be to use PRIMARY and CUT_BUFFER0. That's what xterm
> *noddy* version of X11 clipboard handling.
> That is to say, whenever vim grabs & writes to the PRIMARY selection,
> it'll also do the CLIPBOARD selection. Plus, whenever a paste from "* is
> performed, if there's a PRIMARY selection, then that is used, otherwise a
> CLIPBOARD selection is searched for and used.
does, thus it should work well together with xterm. Also, the CUT_BUFFER0
atom is avalable as XA_CUT_BUFFER0, thus the extra Xmu library is not needed.
> (test: select some text in netscape, copy it to clipboard, then selectHmm, saying that xterm is doing something wrong is very dangerous. Mostly
> some different text. "* pastes the second text - the PRIMARY. Single-click
> in netscape to abort that selection (so no selection's visible) and "*
> paste again; the original (CLIPBOARD) text is pasted. You can't reall use
> an xterm for this test, since it's PRIM/CLIP handling is a tad messy, and
> it can't really distiguish between the two)
xterm does things right. Perhaps it's Netscape that is wrong?
To work around this problem, we would need an option to set the selection
names that Vim uses (this could be done with an X resource, but I hate those
To make things complicated, perhaps the Visual selection should be used for
the PRIMARY selection (if the 'a' flag is present in 'guioptions'). Only when
explicitly told so, the CLIPBOARD is used for a yank (copy) or delete (cut)
operation. When doing a "*p, the PRIMARY selection, cut buffer and CLIPBOARD
could be tried (in that order?).
> This change would be enough at a pinch to sort out vim's X11 clipboardWhy? I mean, who says how it should work?
> handling, but as I mentioned before, what really ought to happen is that
> "* writes only write to CLIPBOARD, and visual selections will always write
> to PRIMARY if available.
> On the subject of X's CUT_BUFFERs, I've come to the conclusion that noThe "ultimate" solution would be to allow naming the selection, something
> implementation of those would be worth the effort. The best idea was to
> link registers a-h to CUT_BUFFER0-7, but all this would really give you is
> the ability for vims on different machines to share those registers, and I
> think managing the read/write of those every time one of those registers
> is accessed could be fiddly to code, and time-consuming at runtime.
hundred-and-one symptoms of being an internet addict:
8. You spend half of the plane trip with your laptop on your lap...and your
child in the overhead compartment.
/-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
\-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/