On Sun, Mar 17, 2019 at 09:52:34PM +0000, Daniel Abrecht wrote: > On 10/03/2019 23.02, Bill Allombert wrote: > > Could you write a simple test program ? > > The problem with vttest is that it does not inhibit the normal copy > > paste mechanism. So while it correctly detects the button press, the > > result seems useless (try press- move-releas). > > This might explain why gpm use another solution. > > I don't think this is the reason. When I try to select something in a > curses application which uses mouse tracking, gpm doesn't select what I > want it to, but it does copy what I select. GPM also seams to disables > pasting in that case. Other graphical terminal emulators seam to disable > selecting, copying and pasting while an application uses mouse tracking. > > The linux console (fbcon) also clears any selection if anything is > written to the tty, even if the screen content doesn't change because of > it.
Precisely, it removes the selection highlighting, but the content of the selection buffer is not altered, as pasting show. > I don't know if the curses library would do that automatically, but > some curses applications may do that. For some reason, a button release > mouse event also seams to clear the selection. In which situation ? > In any case, unless how > the linux console handles selections in such situations is changed, > there is no way to use mouse reporting and text selection > simultaneously, regardless of how the mouse reporting is archived. > > I'm not sure what the best course of action is. Some possibilities are: > * If it isn't too much of a problem, we could just leave it how it is. > * We could disable selections while mouse tracking is active If this can be done on a per tty basis, this might be the best course of action. Thanks for your patches! I will look at them when I have a bit more time. Cheers, -- Bill. <ballo...@debian.org> Imagine a large red swirl here.
