No API or Sequences to change BaseY

[McDaddy]

My case is user scroll content to the top and load more content from the top

I've searched the issue and I found onScroll can't be trigger by user scroll，currently the problem is I'm trying to move cursor up to top by sequence \x9B100A，but it can only reach to the current viewpoint top，I guess the root cause is the term.buffer.active.baseY is never get updated? I even tried to resize the term, but no luck

Details

• Browser and browser version: Chrome latest
• OS version: 14.1.2 (23B92)
• xterm.js version: 5.3.0

[jerch]

I'm trying to move cursor up to top by sequence \x9B100A，but it can only reach to the current viewpoint top

Yes, it is not possible by any means to move the cursor further up. Thats a general restriction of terminals with a scrollback, not only xterm.js. The cursor addressable area is only the lower part of the scrollback.

This also means, that you cannot change that behavior by just changing some settings on xterm.js, it would need a fundamental rewrite of the buffer & cursor handling in xterm.js itself making it incompatible to other terminal emulators.

If you want a more editor-like view behavior, with bigger scollback, then you'd have to write a terminal editor, that does the buffer content juggling by its own buffer abstraction on the alternate buffer in xterm.js. Thats how vim/emacs etc. do it. Alternatively you could also use an editor component like monaco in the first place for your data to be shown, if there are no other cmdline-like features needed.

[McDaddy]

I'm trying to move cursor up to top by sequence \x9B100A，but it can only reach to the current viewpoint top

Yes, it is not possible by any means to move the cursor further up. Thats a general restriction of terminals with a scrollback, not only xterm.js. The cursor addressable area is only the lower part of the scrollback.

This also means, that you cannot change that behavior by just changing some settings on xterm.js, it would need a fundamental rewrite of the buffer & cursor handling in xterm.js itself making it incompatible to other terminal emulators.

If you want a more editor-like view behavior, with bigger scollback, then you'd have to write a terminal editor, that does the buffer content juggling by its own buffer abstraction on the alternate buffer in xterm.js. Thats how vim/emacs etc. do it. Alternatively you could also use an editor component like monaco in the first place for your data to be shown, if there are no other cmdline-like features needed.

@jerch thx, maybe I did't describe my issue well， the purpose to move cursor up is not to edit data from top, but load more data like log data, if there is any method to append the buffer without cursor move, I think that will be great

[jerch]

Well the terminal maintains a customizable scrollback for the default buffer - maybe thats all you need? Appending data is easy, just write more data to the terminal (append '\r\n' for real new lines). The scrollback will show the last n terminal lines of that data, if you choose n big enough, the whole data will be accessible for the user by scrolling in the div element.

Not sure why you'd need the scroll offset of the div to be programmable for that?

[McDaddy]

Well the terminal maintains a customizable scrollback for the default buffer - maybe thats all you need? Appending data is easy, just write more data to the terminal (append '\r\n' for real new lines). The scrollback will show the last n terminal lines of that data, if you choose n big enough, the whole data will be accessible for the user by scrolling in the div element.

Not sure why you'd need the scroll offset of the div to be programmable for that?

@jerch I think I mislead u again, Let me explain my issue, step by step

1. when initialization，I just load 10 history records in the terminal
2. If user try to scroll up to the top, I will fetch next 10 history records and render the data at the top of the whole buffer
3. I fetch data via rest api not websocket

to be short, my purpose is keep the cursor unchanged and insert data at the beginning of the whole buffer. Hope I explain clear this time😄

[jerch]

Oh well, thats prepending, not appending. Well prepending is not supported, the terminal buffer only works in appending direction.

What you describe is a pager like more or less at the command line - cant you simply use those?

[McDaddy]

Oh well, thats prepending, not appending. Well prepending is not supported, the terminal buffer only works in appending direction.

What you describe is a pager like more or less at the command line - cant you simply use those?

yes, that's prepending😂， I don't know what do you mean by "simply use those"... can you help to give more detail? btw, I need to clarify again, I fetch data via rest api not websocket

[jerch]

Well simply like that:

$> less big_bunch_of_log_data

This gives you a view within the terminal, where the user can jump through the data with up/down arrows or page-scroll up/down.

[McDaddy]

Well simply like that:

$> less big_bunch_of_log_data

This gives you a view within the terminal, where the user can jump through the data with up/down arrows or page-scroll up/down.

@jerch thank you! actually what I am loading and prepend is not file content but command history, so that I don't think we can act like more or less.

currently my workaround is save buffer content in local and reset the whole term, then write the loaded content, finally write the saved buffer content as concat. It looks good so far