Added option to disable text selection

[simast]

This PR adds a new terminal option - enableSelection. I think it's a valid use case where regular terminal text selection is undesirable (one example would be a curses based game).

This option is set to true by default - meaning by default there is no impact for existing integrations.

Example usage:

const term = new xterm.Terminal({
  enableSelection: false // To disable text selection
});

const enableSelection = term.getOption("enableSelection");

term.setOption("enableSelection", true);

Some implementation notes:

• I am not sure how the flag should be named as right now both enable/disable naming formats are used (example would be disableStdin and enableBold).
• I have preserved the special selection mode (with a modifier key) when terminal is in mouse event mode. Although previously it was quite confusing that SelectionManager.disable() would actually put terminal into this mode (as selection was not disabled). Therefore to fix this I have modified the disable() and enable() methods to be used for disabling and enabling text selection (and mouse input mode is now handled based on terminal.mouseEvents flag).
• Default mouse cursor is used when text selection is disabled (like with mouse event input mode).
• This will also disable text selection using existing public APIs (and with a Cmd+A key).
• I had a look at existing tests - although I could not figure out how to mock and cover this functionality without exposing some private fields as protected.

[Tyriar]

@simast I'm not sure I understand the need for this; a curses-based game would enable mouse events which does disable selection (excluding the forced selection via a modifier)?

[simast]

I'm not sure I understand the need for this; a curses-based game would enable mouse events which does disable selection (excluding the forced selection via a modifier)?

I don't think that enabling mouse events is a proper workaround to disable text selection. Very few roguelikes using actual terminal output will bother implementing mouse events. Enabling, receiving and then ignoring those events when you do not actually support them is also far from ideal. Besides, having shortcuts like Cmd+A select all terminal is also undesirable in a game.

I think those are two different unrelated options as you can have both mouse events with disabled text selection and the other way around.

[Tyriar]

@simast seems unintuitive to force the user to go and configure their terminal when they want to play said game though. Maybe I missed it but I think xterm.js acts just like other terminals right now with the override to force selection (just checked terminator and gnome-terminal). I couldn't see any other terminals that provide such a setting as well.

[simast]

But xterm.js is a library, not a standalone terminal application. This setting is not for the end-user but for the library user - someone who chose to embed xterm.js in a website or an Electron app. I honestly don't understand why is there an issue to make it more configurable?

[Tyriar]

@simast trying to prevent bloat; the larger the API surface, the harder it is to maintain and the larger the payload. I suspect you are one of only a small handful of people who desire such a setting.

To be clear, xterm.js isn't meant to be a platform in which to ship programs with, but rather a library to implement terminals with. This is however a good candidate for the sort of thing we want custom addons to enable, which we're discussing in #1128 and #808.

[Tyriar]

Closing this off as there are no plans to include this in the core lib as explained above.