Nedit & KDE loss of selection problems

[Joerg Fischer]

Daniel Eischen wrote:


> Could it be that a clipboard selection event (or whatever it is
> called) is generated every time the text is moved?  And for NEdit,
> the second event is a noop because the selected text hasn't changed;
> it has only moved.  As a result, nothing gets (re)copied to the
> clipboard.

My speculation is that it is correct that there is sometimes no
selection in nedit although might not notice.

I looked a bit deeper into this, with kde 3.5.1, but you're using
3.5.6 and according to the bug report they won't do anything about it
anyway. 

First off, this is all for klipper with the option "Prevent empty
clipboard". If this option is deselected, everything works. Moreover,
I'm using OpenMotif, so there is no relation to Lesstif.

What I found is that shiftLeftTabAP always works (even with set
emtabdist to 1), but shiftLeftAP gets deselected half of the time,
more precisely, when something was selected before hitting Ctrl+0.
This seems curious, because the code inside nedit is almost identical,
the only difference being in the calculation of the shift distance,
which shouldn't matter at all.

Then I tried the following simple macro

deselect_all()
select(0, 10)

The macro works almost every time if nothing is selected and fails if
something is selected.  Again, the code run is identical -- deselect_all
does exactly the same thing whether or not anything is selected.

My speculation is that the problem has something to do with the fact
that the selection you see in nedit cannot always be maintained at any
intermediate step you don't see. (And that the sporadic different
results are due to klipper checking at times or not, while the nedit
code executed is identical.)

That is, notice that when you select something and let nedit perform
an editing operation on the selection (yes, there is more than just
copying the primary selection to a clipboard), then when replacing the
text there is temporarily no X selection in the nedit buffer[1].  This
shouldn't be a problem (because the text in the buffer changed so that
the old selection isn't uptodate) and no reason to worry, because nedit
will do a new selection taking care of the new start and end positions
-- unless, well, unless you have klipper running that detects sometimes
'Oh there is no selection so I'm inclined to intercept' and the damage
is done.

Now draw your own conclusions of who is to blame.

(Mine is that if klipper sees an empty selection for whatever reason,
it simply shouldn't copy the empty string into its clipboard. There is
no reason to do anything more than this.  We don't release code that
shoots kde down and claim the code would not be broken because it does
exactly what it is supposed to do.)

Cheers,
Jörg


[1] This is the normal way of working, btw, select something and type
    then the selection is lost.  It is rather unusual under X to
    change the buffer while keeping a selection there, so that you can
    send the selection to klipper at any time klipper requests so.  I
    also looked at kate, but kate doesn't seem to use the X selection.
    When I select something in kate I can also select something in
    nedit and have both selections at the same time.  But AFAIK there
    is only one primary selection under X. That is, if I have two X
    clients and I do a primary selection in one of them, a possible
    primary selection in the other one should be lost.