Re: XEmacs can't delete big chunks

Thanks, Glynn and Stephen, that sorta worked.  I changed
interprogram-cut-function from own-clipboard to nil.  Performance of
large cuts is much better, but now when I do a simple C-k and C-y, I
get "l^A" instead of the line that was cut.  

-- Pete


  Glynn> Is XEmacs synchronising the X clipboard to the kill-ring? That
  Glynn> can make large kills horrendously slow.
  Glynn>
  Glynn> Check the value of interprogram-cut-function; if it isn't nil,
  Glynn> make its so. That will make kill operations internal to XEmacs;
  Glynn> if you want to copy to the X clipboard, use C-insert instead.

  Stephen> I don't have a 50,000 plus file handy, but 21.5's
  Stephen> src/ChangeLog has >49,000 lines.  C-u 20000 C-k from the top
  Stephen> of file took perceptible time but less than a second, in a
  Stephen> Mule build with full error-checking (*very* slow compared to
  Stephen> a production build).
  Stephen>
  Stephen> The usual culprit is Motif (the Motif clipboard protocol
  Stephen> really really sucks).  See the docs for the variables
  Stephen> `interprogram-cut-function' and
  Stephen> `x-selection-strict-motif-ownership'.  There were also some
  Stephen> changes around 21.5.20 which should result in speedup of
  Stephen> certain motion commands (a bug in the Mule position cache
  Stephen> meant it wasn't caching, so the fix won't help from a cold
  Stephen> start, only once the cache is filled).

  Pete> If I load a big file (>50000 lines) into XEmacs v21.5beta17 and
  Pete> delete a big chunk with, like, C-u 20000 C-k, XEmacs just sucks
  Pete> CPU until I kill it.  My solution: use vi for just this case.
  Pete> I've had this problem for many months (years?) on different
  Pete> machines and versions of XEmacs.  Am I the only one?