On Sun, Aug 15, 2004 at 02:18:09AM -0400, Andrew Pimlott wrote: > On Thu, Aug 12, 2004 at 05:38:15AM -0400, Thomas Dickey wrote: > > It's easy enough to see if xterm is producing the beep (though a quick > > look through the source doesn't show me that it does). Changing the > > control/middle-mouse menu to use Visual Bell would modify this to a > > flash if xterm is producing it, not if the library is doing it. > > Boy, am I dumb. The answer is right in the man page: well, the manpage is long (you're excused). > <BtnUp>:select-end(PRIMARY, CUT_BUFFER0) \\n\\ > <BtnDown>:bell(0) > > I got thrown off because I had been trying to override this by binding > <Btn6Down>, which as I discovered doesn't exist. But the binding for > <BtnDown> does catch "unknown" buttons. Overriding this binding to > ignore() fixes the beep as expected. > > I assume the idea was to use extra mouse buttons to copy the selection > into a cut buffer, and the bell was just feedback that this had been > done (maybe it was slow on old systems?). Given that the common meaning possibly - I see that in the X11R3 version, so it's very old. Buttons 4 and 5 were inserted into the list without really changing the other behavior (much). > of buttons >3 seems to have changed over the years, perhaps those > bindings should just be removed. Or as a compromise, the bell could be > removed, since I doubt that copying to CUT_BUFFER0 does any harm, and I > doubt the feedback is critical for the three users of this feature. :-) that sounds reasonable (though I expect there's _someone_ using the feature). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Attachment:
pgpyTRn9TZ6MZ.pgp
Description: PGP signature