Clear command not work as expected when scroll exist. the history is not display

[ofirrifo]

Details

• Browser and browser version: chrome
• OS version: mac
• xterm.js version: 3.9.0

Steps to reproduce

1. run your demo
2. write ls command couple of times until you see a scrollbar
3. write clear command
4. scroll to the top to see the history
   we can't see all the history.

[mofux]

This is the expected behaviour. The clear command usually clears all lines in the active part of the screen, pushing up the prompt to the first line. Everything outside the screen (what is in your scrollback) usually won't get touched by the clear command.

[ofirrifo]

@mofux
I just record Iterm vs xterm.js in order to show the expected behavior.
video
as you can see from the video I test the xterm.js and the Iterm
by:

1. first I run the pwd command in both terminals
2. then in each terminal I run the ls command 4 times
3. then I run the clear command in both terminals
4. then I scroll up on both terminal

as you can see from the video the iterm display all history but the xtermjs diplay
the pwd and the first ls command which is not the expected behaviour

[mofux]

I can confirm iTerm as well as Terminal.app push all screen lines above the active prompt line into the scrollback buffer, whereas we simply erase those lines and don't send them to the scrollback:

xterm.js/src/Terminal.ts

Lines 1740 to 1758 in d27b43d

	/**
	* Clear the entire buffer, making the prompt line the new first line.
	*/
	public clear(): void {
	if (this.buffer.ybase === 0 && this.buffer.y === 0) {
	// Don't clear if it's already clear
	return;
	}
	this.buffer.lines.set(0, this.buffer.lines.get(this.buffer.ybase + this.buffer.y));
	this.buffer.lines.length = 1;
	this.buffer.ydisp = 0;
	this.buffer.ybase = 0;
	this.buffer.y = 0;
	for (let i = 1; i < this.rows; i++) {
	this.buffer.lines.push(this.buffer.getBlankLine(DEFAULT_ATTR));
	}
	this.refresh(0, this.rows - 1);
	this.emit('scroll', this.buffer.ydisp);
	}

@Tyriar Could / should we be smarter with this? I remember there was another (old) issue open where we discussed clear behaviour, but cannot find it right now.

[mofux]

Pardon me, Terminal.clear is definitely not what gets called when running the clear command in the prompt. In case of bash and zsh on OSX it's this:

xterm.js/src/InputHandler.ts

Lines 788 to 795 in d27b43d

	case 2:
	j = this._terminal.rows;
	this._terminal.updateRange(j - 1);
	while (j--) {
	this._resetBufferLine(j);
	}
	this._terminal.updateRange(0);
	break;

[jerch]

@mofux I think we had several issues regarding this. A proper solution does not exist, its not officially specced anywhere beside some oldish VT stuff (which does not deal with scrollbuffer things). Imho there are 3 different approaches to deal with it as seen by other emulators:

• delete active screen (what xterm.js and xterm does, this is the closest you get VT spec-wise)
• push active screen into scrollbuffer (seems the case for vte based emulators and iTerm)
• delete whole screen + scrollbuffer (I think thats what windows console does)

Note that its not easy to adopt the other behaviors - clear typically sends a combination of several escape codes (I see here CSI H + CSI 2J, not even sure if this might differ on BSDs and such). We could change CSI 2J (ED2) to always push into the scrollback, but this might break with other apps. For deleting scrollback we have CSI 3J (ED3).

Other issues regarding this: #1727, #587, #106.

Edit:
The manpage on linux states:

clear clears your screen if this is possible, including its scrollback buffer (if the extended "E3" capability is defined). clear looks in the environment for the terminal type and then in the terminfo database to determine how to clear the screen

Lol guess the terminfo entry xterm.js is referring to is wrong here, it misses the ED3 thing. The intention of clear is clear - delete all, if possible including the scrollback.

[Tyriar]

Looks like this is an exact dupe of #1727