term.getSelectionPosition().start.y is not cursorY?

[alanhe421]

Testing found that for example xterm.js only renders a total of 24 lines, but when I use selectionPosition,I found that this y can be more than 24?

Code

term.onSelectionChange(() => {
  const selection = term.getSelection();
  if (!selection) {
    return;
  }
  const selectionPosition = term.getSelectionPosition();
 
  console.log('选中文件', pathJoin(cwd, selection), cwdArr, selectionPosition);
});

[jerch]

@alanhe421 The selection coords address the whole terminal buffer, thus y here is the 0-based index from top of the whole buffer included scrolled off lines.

[alanhe421]

term.parser.registerOscHandler(1337, data => {
  const currenDirArr = data?.match?.(/(;CurrentDir=)([^;\u0007]+)/);
  if (currenDirArr?.length >= 3) {
    cwdArr[term.buffer.active.cursorY] = currenDirArr[2];
  }
});

So term.buffer.active.cursorY doesn't cover the scroll-off part?

I need to be able to record the captured CWD and the corresponding terminal line number when OSC is processed; if I follow your description, then I am using the term.buffer.active.cursorY incorrectly here. Is there a way for me to fetch the full Y coordinate?

[jerch]

So term.buffer.active.cursorY doesn't cover the scroll-off part?

Yup, it addresses only the cursor-addressable-area (also 0-based). That cursor-addressable-area is one viewport in height at the bottom of the whole buffer.

I need to be able to record the captured CWD and the corresponding terminal line number when OSC is processed; if I follow your description, then I am using the term.buffer.active.cursorY incorrectly here. Is there a way for me to fetch the full Y coordinate?

Looks like you want to scrape the buffer. Thats quite wonky, how do you know where the string starts resp. ends? Doesnt that OSC sequence have additional payload with the folder name somehow?
To get the total offset in the buffer, just add term.buffer.active.baseY + term.buffer.active.cursorY.

[alanhe421]

So term.buffer.active.cursorY doesn't cover the scroll-off part?

Yup, it addresses only the cursor-addressable-area (also 0-based). That cursor-addressable-area is one viewport in height at the bottom of the whole buffer.

I need to be able to record the captured CWD and the corresponding terminal line number when OSC is processed; if I follow your description, then I am using the term.buffer.active.cursorY incorrectly here. Is there a way for me to fetch the full Y coordinate?

Looks like you want to scrape the buffer. Thats quite wonky, how do you know where the string starts resp. ends? Doesnt that OSC sequence have additional payload with the folder name somehow? To get the total offset in the buffer, just add term.buffer.active.baseY + term.buffer.active.cursorY.

I want to implement a file download where the user double-clicks on a file name.

Then I need to record the CWD information of each line according to OSC, so that when the user selects a file, I can match the position information according to the position. xterm.js does not have this information in the buffer, so I have to record the mapping between CWD and line number by myself.

[jerch]

And how do you know, that the printed chars denote a filename? To get this halfway reliable working you need the shell/ls to cooperate and place marker sequences around the filenames. I am not sure, if there is a ready to use sequence for that, or if you are on your own here.
You can get something similiar with OSC 8 hyperlinks - your ls process could mark the filename as url with a custom scheme and a resolvable path. On xtermjs side you then need to create a custom link handler, that would understand that scheme and trigger a custom logic to retrieve the file's content.

Also see #4943, which is a more generic idea to solve the content transport idea in terminals.