Visual marker at end of the selection and selectionStyle option to Terminal

[akariv]

We introduce a new configuration option - selectionStyle - used to style the text selection layer.
It has three 'modes': plain (the current default), mark-end (add a marker to the end) and mark-start (add a marker to the beginning of the selection range). The styling of the marker is taken from the theme itself.

The use case here is when integrating with applications that need to allow manipulating either end of the selection range via keyboard, and we need a way to show the user the currently 'selected' end.

mark-start:

mark-end:

[jerch]

Thats an interesting feature. When you write

...to allow manipulating either end of the selection range via keyboard, ...

Does that mean you have to move the cursor? Or how do you do that? If it involves cursor movements, how do you go about selections in the scrollback (not addressible by the cursor)? And how do you sync that with the application?

Sorry for so many questions, maybe you could explain it and the actual use cases abit more in detail?

[daonb]

hi @jerch, this is a feature we need for Terminal 7. Adam is a friend who loves TypeScript so his helping me with one of the key features we're missing for 1.0 - tmux style copy mode : tuzig/terminal7#66 .

In the past I tried and failed in developing this feature. The cursor is stuck on the bottom page and that's the way xterm.js is. Adam had a great idea: to let the cursor be and use the selection start|end instead. This PR is just a part of the feature, the other being a copy-mode plugin to use this new option. Here is the code, it's still under works and part of terminal7 but not for long.

[Tyriar]

I have a few concerns with this:

• Not a fan of introducing selectionStyle setting, it's very specific to Terminal 7's particular case and I doubt anyone else would end up using it
• It's only implemented in the canvas renderer, it would need to be added to both DOM and webgl as well if we did this

This is awfully similar to something I've wanted xterm.js to do for a while which is to just allow manipulating a cursor (not the actual cursor) within the buffer to enable:

• Navigating and selecting via the keyboard
• Reading of the character/word for screen readers

You would enter such a mode somehow and then exit it via escape. So I'd be all in for getting that or something that works towards that in.

---

I'd like to propose an alternative to this change, all you seem to need is to be able to mark the start and end of the selection, essentially allowing embedders/addons to add decorations to parts of the buffer which we have an open issue on: #1852

There's some discussion in that issue but my basic thinking would be to have an overlay element (.xterm-decorations) that uses pointer-events: none and allows addons to decorate certain ranges in the buffer. For your case this would involve decorating the range and then filling in the style to what ever you want, a very quick example:

const s = term.getSelectionPosition();
const decoration = term.decorateRange({ 
  x: s.startColumn,
  y: s.endColumn
});
decoration.element.style.border = '1px solid #fff';

Some thought would need to be given to the exact shape of the API, but the big benefits here is that is aligns with our goals and it would end up being used by several embedders (including VS Code, eg microsoft/vscode#46561).

[akariv]

Yes, implementing this as an add-on would have been my first preference - but modifying the style of the buffer seemed to be impossible with current API.

I'll take a stab at implementing the decorations API (or a first draft of it, at least)

[Tyriar]

@akariv I'd recommend approaching it in a similar way to how RenderService works:

• Create a DecorationService in the style of other services inside the browser/ layer
• Pass a decorationElement in when it's instantiated
• Rely on IBufferService so you can listen to onScroll and ask decorations to update

[akariv]

Closing this as we've opted for another approach.