should allow moving cursor with mouse

[PerBothner]

It's difficult to explain to non-geeks that you can't re-position the cursor with the mouse - and it's even (occasionally) annoying to us geeks!

The Python Prompt Toolkit supports using the mouse. It has similar goals as JLine3 (but for the Python eco-system), so it may be worth studying their solution.

[gnodet]

Fwiw, on OS X + Terminal, mouse pointing and mouse scrolling do work. When pointing with the mouse and the option key, one or more key_left / key_right sequences are sent. When using full screen mode as in the jline less command, key_down / key_up events are sent when scrolling.
The scrolling works really great in Yosemite or El Capitan. El Capitan also supports Mouse Reporting to be notified of clicks and their positions, but I haven't investigated which sequences are sent.
iTerm also seems to send key_up/down/left/right when option-clicking by default.

On windows, the AbstractWindowsTerminal needs to be enhanced to support reading mouse events. Unfortunately, jansi does not have the required structures. The JNA Kernel32 library can easily be extended to provide the necessary structures for MOUSE_EVENT_RECORD.

On unix, xterm usually sends a CSI sequence ending by M as explained here.

[PerBothner]

Having to type Option along with a mouse click is not very intuitive or "discoverable". How many terminal emulators support this feature (or the Windows equivalent)? And how many people know about it?

Plain mouse clicking should just work - it's what people expect.

The advantage of Option+click is that it's a feature that can be implemented purely in the terminal emulator, without agreeing on a particular protocol. (It's an idea worth considering for DomTerm.) However, there is already an existing protocol implemented by xterm and most "xterm-compatible" terminals - but it does require client/library support.

One complication is that an xterm mouse event tells you row/colum, but it doesn't tell you the position relative to the current cursor position. JLine knows the column, but only the relative row number. So it has to ask the terminal, but might have some complications with synchornization or timeouts - I haven't really looked into it. Seeing what the Python Prompt Toolkit does might be instructive.

DomTerm+JLine3 works great on Windows, and I can't imagine any reason why mouse clicking wouldn't work, as long as JLine adds the needed support.

[gnodet]

I've experimented a bit with xterm based mouse support.
It seems to work great on OSX El Capitan terminal.
I've added mouse support on the nano editor in the PR.

[PerBothner]

Cool! For LineReader support, we also need the initial cursor position.

A simple idea is to emit Report Cursor Position ("\033[6n") before printing the first prompt.
Then hopefully the terminal will (soon) report the CursorPosition, which we handle like other keyword events. The returned position will then by that of the top line left column, which we can use for an origin when/if a mouse event comes in.

Scrolling will complicate the origin calculation, but if we know the initial position and the maximum number of lines we've emitted, we should be able to adjust for scrolling.

An alternative to to emit a Report Cursor Position when one gets the mouse event. One could defer the handling of the mouse event (just stash it somewhere) until the Cursor Position response comes in.

[gnodet]

Feel free to have a look at gnodet@8dd71d6
It needs to be finished on windows + jna (jansi does not provide the needed features), but it seems to work nicely.

[PerBothner]

Preliminary tests are good.

I will try it on Windows using DomTerm. There is no inherent reason it shouldn't just work.

[PerBothner]

Using the mouse sort-of works on Window when using DomTerm.
However, I get a various Java exceptions (different ones if using the Command Prompt or the MinGW terminal). I haven't looked too deeply yet,