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