Loading ...
Sorry, an error occurred while loading the content.

Re: X11 clipboard patch beginnings

Expand Messages
  • Bram Moolenaar
    ... The code helps us to get this going, very good. ... An alternative would be to use PRIMARY and CUT_BUFFER0. That s what xterm does, thus it should work
    Message 1 of 2 , Apr 12, 2000
      Neil Bird wrote:

      > OK, well nobody had any comments on my earlier posting about the X11
      > clipboard, so I've made a little stab.

      The code helps us to get this going, very good.

      > Attached is a patch to ui.c (from within /src) that implements the
      > *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.

      An alternative would be to use PRIMARY and CUT_BUFFER0. That's what xterm
      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 select
      > 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)

      Hmm, saying that xterm is doing something wrong is very dangerous. Mostly
      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 clipboard
      > 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.

      Why? I mean, who says how it should work?

      > On the subject of X's CUT_BUFFERs, I've come to the conclusion that no
      > 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.

      The "ultimate" solution would be to allow naming the selection, something


      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 --/-/
    Your message has been successfully submitted and would be delivered to recipients shortly.