problems with enabling MOUSE option

[PerBothner]

While enabling the new MOUSE option works pretty well, it has some annoying downsides: It interferes with mouse actions that aren't plain clicks. Specifically: selecting by dragging the mouse; middle-button-paste; right-button context menu; and scrolling using a wheel-mouse.

Most "xterm-compatible" terminal emulators allow you to get most of the default actions by using a shift-click (though mouse-scrolling doesn't work). However, this requires knowing (and remembering) to hit shift.

I'd like a mode such that:

• clicking mouse-button-1 (non-shifted) is reported to the application
• (on appropriate platforms:) middle-button-click reports the position the same way as mouse-button-1 and then the contents are the selection are sent to the application, using bracketed-paste-mode, similar to how a paste (ctrl-shift-V) works
• all other mouse events are unmodified

Unfortunately, I don't believe there is any existing standard escape sequence to get this behavior. It should be easy enough to add for specific terminal emulators (I could do so for DomTerm), but it would be highly desirable to get at least Thomas Dickey (the xterm maintainer) to bless and document any new escape sequences.

(Architecturally, it would be better to move more of the editing into the terminal emulator, where we can integrate keyboard, mouse, selection, input methods, assistive technologies etc better. That is part of my vision for DomTerm. However, we should also improve the experience on more traditional terminal emulators.)

[gnodet]

I think in most situations, the terminal can handle all mouse inputs by sending cursor movement for moving the cursor, doing the selection, support copying the selection and pasting, etc...
It may not always work if an application require a very deep integration, but I'm not sure I understand what you're looking for, as any JLine app can already do the 3 points above afaik.

[PerBothner]

I don't believe "any JLine app" can do the 3rd item in my list: Currently, if I enable the MOUSE option, then the following break, unless I remember to press shift: selection by dragging (and thus I can't copy from the terminal); middle-button-paste; and mouse-wheel scrolling (which doesn't work even when shifted). This is annoying - and confusing to most people.

Emacs-in-a-terminal does its own highlighting and selection when the mouse is dragged, but this is not integrated with the system selection or clipboard. I'm not sure JLine3 should attempt something similar. It would be better IMO to use the terminal's builtin highlighting and selection.

I think there should be one more item to the list:

• dragging the mouse with button-1 pressed should report both the start and ending position, but the terminal emulator should use its default highlighting and selection. This allows a reasonable amount of flexibility: copying to the system selection or clipboard (by the terminal emulator), or emacs-style region copying/killing (within JLine).