Make scroll-to-bottom on input behaviour configurable

[Eugeny]

xterm will unconditionally scroll to bottom on user input: https://github.com/xtermjs/xterm.js/blob/master/src/Terminal.ts#L1518

It'd be handy if this could be programmatically disabled.

[Tyriar]

@Eugeny are you sure that's the right fix for Eugeny/tabby#543? This particular case in VS Code is handled by this option which let's you force normal selection (not apply tmux selection) and copy that way:

xterm.js/typings/xterm.d.ts

Lines 150 to 157 in b5f1c33

	/**
	* Whether holding a modifier key will force normal selection behavior,
	* regardless of whether the terminal is in mouse events mode. This will
	* also prevent mouse events from being emitted by the terminal. For example,
	* this allows you to use xterm.js' regular selection inside tmux with
	* mouse mode enabled.
	*/
	macOptionClickForcesSelection?: boolean;

[Eugeny]

Judging by

But with Terminus, when you press space, it doesn't let you enter select mode. Instead, it jumps you to the bottom of the tmux window.

I'd say that's the case

[Tyriar]

@Eugeny but tmux doesn't have access to the scrollback, it maintains it's own scrollback buffer which is why this is confusing me. If you were using tmux's copy mechanism, you must be at the bottom of the (xterm.js) viewport?

[Tyriar]

After more discussion in Eugeny/tabby#1578, it's not to do with tmux apparently, people just want the option to disable it so accidentally hitting a key doesn't scroll.

Proposal for new option:

scrollOnInput?: boolean; // default true

[jerch]

@Tyriar Not sure how this is currently coupled to input - is the scrolling triggered by keyboard input or by pty output (thus term.write input)? Imho most other emulators couple this to latter one like xterm with its Scroll to Bottom on TTY output setting.

Edit: There are two DECSET modes from rxvt, which further specify this:

• 1010: Scroll to bottom on tty output
• 1011: Scroll to bottom on key press

xterm updates its settings directly from these (thus applications are allowed to change it).

Proposal - support both as well, but rename tty output to write (since we are not strictly bound to pty/tty output):

  scrollOnWrite?: boolean;    // default true, same as DECSET 1010
  scrollOnKeypress?: boolean; // default false, same as DECSET 1011

+support for DECSET 1010 / 1011.

[Tyriar]

@jerch 👍 the Terminal options should probably override the DECSET modes though?

  scrollOnWrite?: boolean;    // default undefined, respect DECSET 1010
  scrollOnKeypress?: boolean; // default true, override DECSET 1011

[jerch]

@Tyriar xterm seems to allow to change that by apps on the fly. Imho for those things the user should always be in control - I agree with you.

Edit: Given that - maybe we should not bother with DECSET here? Imho app side is seen as restricted to active viewport manipulations (cannot interact with scrollbuffer at all), I dont see any valid use case for DECSET 1010/1011 beside messing with user settings. So skip it and go only with those options?

Edit2: Another way to deal with it and have DECSET support would be a 3-state option:

• undefined (not touched from options, thus allow DECSET updates)
• true/false (explicitly set from options, thus DECSET is disabled)

Not sure if the implementation overhead for that is worth anything, still see no value in the DECSET modes here.

[Tyriar]

Another way to deal with it and have DECSET support would be a 3-state option

This is what I was suggesting, we might be over thinking it though and adding a thing no one would use? It's similar to the cursor style sequence that I added which doesn't have a 3 state thing, instead the sequence updates the option and that's the source of truth.

[jerch]

Well I currently lean towards having the options only, no DECSET at all for this. Would be straight forward to implement. Imho application side should not be able to alter those settings (thus DECSET 1010/1011 are ignored like now). I really dont get why these settings have DECSET modes at all (maybe I just dont see the valid use cases).

[killjoy2013]

I'm using xterm in Reactjs and just upgade to 4.8.1. My app constantly writing long SSH output chunks to terminal. Default behaviour is to scroll to bottom whenewer a new text chunk is written. My app's user is supposed to activate / deactivate this behaviour. i.e, he'll freeze the terminal to prevent this scroll to bottom thing as he wishes. Couldn't find a way. Is it possible to switch scrollTtyOutput behaviour in the app?
Thanx

[Tyriar]

Added in #4289

[JasonXJ]

Hi Tyriar, I wonder whether we want to keep this issue open as the other option "scrollOnWrite" still haven't been implemented?

[Tyriar]

Was a long time ago that we discussed this, I don't think scroll on write is ever really desirable is it?

[JasonXJ]

Personally, I don't use it. But in the older version of our app which supports it, I can see that ~1% of users use it.

Another thing is that it is not hard to implement "scroll on write" outside of xterm.js --- we just need to subscrube to onWriteParsed() event and then call scrollToBottom(). It might still be nicer for xterm.js to support it directly though.

I will leave the decision to you.

[Tyriar]

Since the usage should be low and it's trivial to implement by the embedder I think we can leave this out. Key press on the other hand was enabled by default so the embedder didn't have a choice.

[CaledoniaProject]

This is still not implemented in xterm? It's quite a common feature in other desktop terminals.