Lydgate <[EMAIL PROTECTED]> writes: > But if I understand you correctly, even adding 6 and 7 in X would not be > enough, and buttons 6 and 7 would need to be defined in elinks? > Although I would think that something like: <Btn6Up>:U\n\ would bypass > that limitation (assuming default keybindings) along with binding Btn7Up > to "Left" (although I'm not sure exactly what string this would be).
If the terminal sends ESC [ D, ELinks treats that as the Left key. In C syntax, that is "\033[D". I don't know whether libXt understands the same syntax. However, if you're editing an input field in ELinks and press Left, ELinks just moves the cursor to the left inside the input field, instead of going back in the history. If you want mouse button 7 to access the history in this situation too, you should translate it to a string sent by some other keystroke, and then map that keystroke to history-move-back in ELinks. These workarounds make ELinks treat buttons 6 and 7 as keyboard keys. A proper solution would let ELinks treat them as mouse buttons, but then the event would have to carry the coordinates of the mouse pointer as well, so it would probably require patching both xterm and ELinks.
pgpFw4ycN2jKO.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
