Newer protocol for extended mouse clicks

[egmont]

This is a followup of ticket 2662.

MC currently has support for mouse clicks beyond column 223, using urxvt's "SGR 1015" extension.

A followup extension, "SGR 1006" was invented by xterm, to overcome some of the shortcomings of the previous one. It is becoming as widespread as the previous one, and is likely to soon overtake it in popularity. Some developers are actually quite against adopting two extensions, and are likely to stick with the newer ones. (Actually I had a hard time convincing vte's developer not to drop urxvt's extension yet, but he might want to drop it after a while.)

I attach a patch which changes MC to use this newer extension, instead of the older one.

Note that most of the patch is just the removal of the huge complexity introduced by the previous one. The previous extension didn't have a unique prefix which made the whole parsing logic extremely complicated. The new extension does have a unique prefix, so parsing becomes a piece of cake. The code becomes much cleaner and much easier to maintain.

Could you please apply this patch to the development branch? This would be a huge step towards settling down in one of these extensions, rather than carrying around the crazyness of more of them, and to be able to retire the 1015 extension in a few years.

[egmont]

Replacing older 1015 extension with newer 1006

[egmont]

Just for the record, current adoption of the two extensions are, according to my best knowledge:

Apps:
Vim (7.3.700-ish): both
Emacs (24.2.9x dev series): newer 1006 mode only, it definitely won't support the older 1015 (would require really heavy redesign and refactoring, even extending their interface between C and Lisp)
Ncurses's mouse lib (used by e.g. htop): developer acknowledged the lack of feature, he'll add at least 1006 (since he's the same guy as xterm's developer), I doubt he would add the older 1015.

Middle layer:
Tmux: patch exists for newer 1006 mode (​http://sourceforge.net/p/tmux/tickets/26/), developer says he'd like to see one extension only
Screen: patch exists for newer 1006 mode (​http://lists.gnu.org/archive/html/screen-devel/2012-07/msg00004.html)

Terminals:
xterm: 277 supports both extensions
vte: 0.34.1 supports both extensions
konsole: 4.10 (to be released in two weeks) supports both extensions
putty: svn (pre-63) supports both extensions
iterm2: dev snapshot 1.0.0.20120726 supports both
st (suckless): git (pre-0.4) supports newer 1006 only
and probably a whole lot more...

and to be fair, let's mention that urxvt currently only supports its own extension, so users of this terminals would see this change as a regression. However, let's look it at this way: MC would join the list of those who try to encourage urxvt's developer to adopt this extension so that after a short transitional period finally everyone settles down at one extension.

[slavazanko]

Would be cool if mc will support both protocols, because we oriented on LTS distros too and dropping support of "SGR 1015" extentions will looks like a regression for these distros.

[egmont]

IMHO:

I intend this patch for mc's development series only, not the currently stable branch. When will that branch become stable, in half a year, or a year from now, or maybe even more? By then, I'm quite sure that all terminals that support the 1015 mode will support the newer 1006 mode too.

This leads to a regression for those users who (logical "and" of these):

• use their terminal straight from their distro, but upgrade mc manually
• use a terminal that's old enough to support 1015 but not new enough to support 1006 (this is a very short time window in the evolution of most terminals)
• use mouse in wide windows

I think this is a quite negligible user base in order not to be worth it with making mc's code more complicated. The bug's been there in decades, these very few users will get the fix another year or two later. In this circumstance I'd vote for cleaner and simpler MC code and to save on developers' resources.

[egmont]

(FYI: Please note that apparently only the newest 1006 extension is called the "SGR" extension, the 1015 extension is not, it's the "urxvt" extension. I don't quite know what SGR is, but this is the terminology used by others, "SGR extension" without number refers to 1006. I used incorrect terminology in my original report, my bad. Just wanted to clarify.)

[slavazanko]

Egmont, can you help me with patching? I have changed your patch, also I made some changes for support both protocols, but I feel that I was wrong somewhere: looks like mouse sends double-clicking on each click, when used 1006 protocol. But all was okay when I applied your original untouched patch. The branch is 2956_mouse_protocol_1006.

Thanks in advance.

[egmont]

I'll look at the patch soon.

At first glimpse: I see you introduced a config option on which protocol to use. I strongly disagree with this decision. It should be solely the job of developers to make clicks work everywhere, not even to the slightest extent the job of our users. Users should not need to know anything about extensions and protocols and magic numbers like 1006 or 1015, and should not need to spend any time browsing configs.

MC should enable both 1015 and 1006 (preferably in this order, so that the preferred 1006 is used if the terminal takes the order into consideration), and parse whichever format it receives. On exit it should disable both extensions (for terminals which have a separate bit for both).

(By the way, as I already stated, I still vote for dropping 1015 completely - are you absolutely sure you would like to keep 1015, at least for a while?)

[slavazanko]

are you absolutely sure you would like to keep 1015, at least for a while?)

Hmm... Probably, I agree with your opinion. The branch will contain only your untouched patch, all other settings-related commits I will move to another temporary branch (for avoid losing of these ideas).

Egmont, thanks for your contribution and help, I very appreciate this.

[slavazanko]

Created branch 2956_mouse_protocol_1006
Initial changeset:e6117504b003d61a9ffa44ebe85d1a51aaf1b18f

review, please.

[slavazanko]

Merged to master:

git log --pretty=oneline 0501ac9..7e115b3

[egmont]

Great, thanks! Let me know if anyone's ever missing the 1015 support, if it's a real requirement I'll be happy to assist in supporting both. I just hope that the new extension will be enough.