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.
@Eugeny are you sure that's the right fix for https://github.com/Eugeny/terminus/issues/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:
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
@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?
After more discussion in https://github.com/Eugeny/terminus/issues/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
@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:
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.
@jerch :+1: the Terminal options should probably override the DECSET modes though?
scrollOnWrite?: boolean; // default undefined, respect DECSET 1010
scrollOnKeypress?: boolean; // default true, override DECSET 1011
@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:
Not sure if the implementation overhead for that is worth anything, still see no value in the DECSET modes here.
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.
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).
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