[Konsole-devel] [Bug 304686] New: Support for xterm's 1006 mouse extension

[Egmont Koblinger]

https://bugs.kde.org/show_bug.cgi?id=304686

            Bug ID: 304686
          Severity: wishlist
           Version: 2.9
          Priority: NOR
          Assignee: konsole-devel at kde.org
           Summary: Support for xterm's 1006 mouse extension
    Classification: Unclassified
                OS: Linux
          Reporter: egmont at gmail.com
          Hardware: Compiled Sources
            Status: UNCONFIRMED
         Component: emulation
           Product: konsole

This is a followup of bug 285984. Could you please apply the attached patch?

The extension in the referred bug (invented by urxvt's author) allows the
terminal to report coordinates beyond 223. However, for multiple reasons,
xterm's author decided to come up with another extension, addressing the same
issue and more. His reasons are, quoting from xterm's changelog:

 o  the responses will not be confused with line-deletion and scrolling
controls. [This matters when using a control sequence that reports back control
sequences, apparently only supported by xterm - this comment was added by me]
 o  the button encoding is a little simpler, since it does not add an
unnecessary 32 because the integer parameter does not have to be represented as
a printable character.
 o  the control responses for pressing and releasing a mouse button differ,
allowing an application to tell which button was released.

My reasons in favor of the new extension are:

 o  It is much easier to patch in support for this new extension into already
existing applications. The urxvt extension, due to the lack of a unique prefix,
usually requires heavy modifications in application sources which look up
escapes in a table or search tree. The new extension has a prefix that you can
recognize and jump into the code that's responsible solely for parsing the
remaining arguments.
 o  Emacs-25 will support this new extension only, and not the other one, see
http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/109093 . The reason is what
I mentioned in the previous point. Implementing the urxvt extension would have
required ugly hacks extending the interface between the C and the Lisp code (as
there's a moment where neither the C engine responsible for generic stuff, nor
the Lisp extension responsible for parsing mouse events knows to whom the
currently seen partial escape will belong to), while the new extension could
easily be implemented solely in Lisp. (And, of course, I have verified that
emacs trunk on konsole with my patch indeed works.)
 o  Similarly, I created a while ago the patch for midnight commander using the
old extension, and I know that most of the bloatware I needed to add could be
removed with the new one. I also created patch for both extensions for the joe
text editor, the one for the new extension is way simpler and more
straightforward, more likely to be accepted by mainstream. I think I have a
good reason to assume that for dozens of other applications out there the
situation would be similar.

A note about the patch: I had to slightly modify the meaning of the arguments
to the sendMouseEvent method, which looks like an externally scriptable
interface. Unfortunately the old semantics only allows to release an
unspecified button, which concept does not exist in the new protocol. Even
though undocumented, the old values passed to the method (i.e. eventType==0 and
cb==3 meaning a button release) still work if the new 1006 mode is off. I hope
that such a backwards compatibility glitch is acceptable (the 1006 mode is
hardly used by anyone yet, it gives a large time frame for everyone to migrate
to the new values), as I have no idea how it could be avoided.


Reproducible: Always

-- 
You are receiving this mail because:
You are the assignee for the bug.