xwinclip interferes with xemacs selection and Re: xwinclip can copyfrom NT to KDE but not from KDE to NT

[James Coleman <James dot Coleman at s3group dot com>]

Hi,

 I have noticed something which may also be related to the KDE problem.
 Maybe not.
 But I think it is worth raising it as a known issue with xwinclip.

 If xemacs (various versions - on linux and solaris) is run under Cygwin XFree86
 and if xwinclip is running then xemacs selection (e.g. Ctrl-SPC move Meta-W for copy)
 gets cancelled by xwinclip. The behaviour xemacs wants is to start a selection
 and not release it until the user does a copy. xwinclip, however works directly
 with the mouse and releases the selection as soon as it is made.

 This could be related with NT <-> KDE as in playing with xwinclip and
 trying to see who should control the release of the selection I can see
 several behaviours where the selection doesn't get handled well and xwinclip
 behaviour changes. I'm not using KDE myself.

 Looking at this with debug on in xwinclip I can see how to possibly work around
 this problem for xemacs (if no text selected ... then assume xemacs and don't release selection).
 This isn't a great workaround (selection using shift+arrow/movement still broken) but it is a start.
 It may be that applications do release the selection and xwinclip should 
 never do this.  I will test this more myself but if anyone else is 
 working on xwinclip they may have a better idea how something like this 
 should be fixed?

 In xevents.c FlushXEvents
case SelectionNotify:
after XGetWindowProperty
something like this:

#if WORKAROUND
          if (fUnicodeSupport)
          {
            if ( xtpText.nitems == 0 && ulReturnBytesLeft == 0 )
            {
               /* workaround for xemacs */
               /* set workaround flag */
               workaroundToStopReassertionOnEmacsBeginSelect = 1;
            }
          }
          else 
          {/* should probably do same */
          }
#endif


then later in same case around XSetSelectionOwner just before break;

#ifdef WORKAROUND
          if (workaroundToStopReassertionOnEmacsBeginSelect == 0) {
#endif
          /* Reassert ownership of the selection */       
          iReturn = XSetSelectionOwner (pDisplay,
                                        event.xselection.selection,
                                        iWindow, CurrentTime);
          if (iReturn == BadAtom || iReturn == BadWindow)
            {
              printf ("Could not reassert ownership of selectionn");
              exit (1);
            }
#ifdef WORKAROUND
          } else {
             workaroundToStopReassertionOnEmacsBeginSelect = 0;
          }
#endif

  So, if you've managed to get to here:

   Can anyone help and say if the release of
    the selection should be controlled by X applications or otherwise?

   Is this a known issue with xwinclip ... is anyone actively working on xwinclip?

  James.