Difference in "force selection" modifier key across platforms

[jaminthorns]

I just encountered the inconsistency of the "force selection" modifier across Windows/Linux and macOS and personally found that a bit jarring:

xterm.js/src/browser/services/SelectionService.ts

Lines 429 to 435 in 0981ca8

	public shouldForceSelection(event: MouseEvent): boolean {
	if (Browser.isMac) {
	return event.altKey && this._optionsService.rawOptions.macOptionClickForcesSelection;
	}
	return event.shiftKey;
	}

I use VS Code on both Windows and macOS, and it would be nice if the modifier was the same across platforms. I couldn't find any technical reason this was done, so I'm guessing it was conventional. iTerm uses alt for this, and since iTerm has a majority "market share" on macOS terminals (at least in my experience working on macOS over the past few years), I'm assuming the modifier choice came from there.

Other cross-platform terminals seem to have settled on using shift as the modifier across the board, though:

• Kitty
• WezTerm

I know that implementing #1536 would fix this, but that seems like a reasonably large endeavor. Is this something that could be resolved with a smaller change?

[jerch]

@Tyriar Is this linked to the observation here #4297 with option+click?

[Tyriar]

@jerch yeah it might help there too.

I can't remember the reason we made this decision originally but it might have meant to be:

   if (Browser.isMac && this._optionsService.rawOptions.macOptionClickForcesSelection) { 
     return event.altKey; 
   } 

We should dig through git history of xterm.js and vscode for clues.

[jerch]

@Tyriar Just a vague guess only - imho we had several discussions in the past about typical key bindings on platforms (this dates way back, was it ~2016/17? - I dont remember), and iTerm was mostly brought up as reference for osx users and their expectations.

on the broader level:

I know that implementing #1536 would fix this, but that seems like a reasonably large endeavor.

I agree, that would be the real fix for it, at least a major part of it (mouse side). The current situation is a bit unfortunate - we have several mouse handlers/listeners spread across the codebase, so this is def. a bigger rework.

The situation gets further complicated by key handling here, which is a convoluted topic itself with partially quite hacky code (result of >>5ys of evolutionary code to cover most browsers/platforms). We had several attempts to clean this mess, but kinda always ended just fixing the old codebase, as the cleaner approaches always had unbearable flaws for this or that.

Some ideas:
An all-in-one solution prolly would be a new input service, which orchestrates event handlers in a key and a mouse subpart (or with separate services), with a high-level API to request this or that behavior, including configurable key mappings and mouse action behavior. We already have rudimentary services for both, but not yet in that bigger configuration & orchestration sense (still scattered atm, and partially even hardcoded as for the issue at hand).

Is this something that could be resolved with a smaller change?

Imho thats possible, but I am not sure if we should introduce just another option for a certain action for osx users only. We already have several osx only options in settings, and tbh I hate them for cluttering the terminal settings. So I wonder if we should swallow the pill and get something like key/mouse profiles running from a unified input service.

[jaminthorns]

@Tyriar's change would indeed resolve my issue. Currently, force-selecting with shift is impossible on macOS. With that change, it becomes the default everywhere (even on macOS), and enabling the macOptionClickForcesSelection setting just changes the modifier from shift to option on macOS.

Looking at the description of the setting in VS Code, there's no suggestion that the code should've been one way or another:

Controls whether to force selection when using Option+click on macOS. This will force a regular (line) selection and disallow the use of column selection mode. This enables copying and pasting using the regular terminal selection, for example, when mouse mode is enabled in tmux.

I personally don't see any harm in making the change. People with "macOptionClickForcesSelection": false get a consistent keybinding to force select across platforms, and people with "macOptionClickForcesSelection": true get to match the force select keybinding of iTerm on macOS. Seems like there's a only a benefit to making that change, but there could be something I'm missing.