Replace the VT based terminal size detection with an API call

[patrickbkr]

Whether this is an improvement or not is up for debate.

[japhb]

Is this PR still required for Windows compatible size detection given that T-LE now depends on Terminal-API 1.0.3?

In other words, is this PR still fixing a real breakage, or just cleanup at this point? (Not that cleanup is a bad thing, I'm just trying to understand the situation.)

[patrickbkr]

On May 14, 2025 2:01:52 AM GMT+02:00, Geoffrey Broadwell ***@***.***> wrote: japhb left a comment (japhb/Terminal-LineEditor#11) Is this PR still required for Windows compatible size detection given that T-LE now depends on Terminal-API 1.0.3? In other words, is this PR still fixing a real breakage, or just cleanup at this point? (Not that cleanup is a bad thing, I'm just trying to understand the situation.)

This is completely unrelated to Windows support. It was only driven by the mantra of "all output - VT, all input - API".

[japhb]

I chewed on this one for a while, and examined the code in Terminal-API. Here are my thoughts:

1. I am not at all opposed to the general idea of leaving T-API to handle querying operations in OS-specific ways for the rest of the Terminal-* stack, but I think the decision comes down to the details.
2. I don't see a lot of win when some queries have to go through T-API and some have to go through ANSI VT queries, as long as those ANSI VT queries are supported on all modern terminals.
3. Currently T-API doesn't have a way to query for cursor position, so T-LE has to support ANSI VT querying for now anyway.
4. It's not clear to me if T-LE or T-W will need more advanced terminal queries in the future, but if so that extends the lifetime of item 3.
5. Whatever querying path used, I'd love to get completely away from using subprocesses to run terminal queries, especially since the commands executed are unlikely to be identical across OSen.
6. Until Rakudo supports varargs NativeCall, T-API is stuck using tput on POSIX, which violates item 5.

So I think on balance I want to keep the current code here for now, but I'm happy to reassess if/when items 2, 3, 4, and 6 are all addressed.

Closing for now, feel free to reopen if you think I'm missing something in my analysis. :-)

[patrickbkr]

On May 15, 2025 5:53:40 AM GMT+02:00, Geoffrey Broadwell ***@***.***> wrote: japhb left a comment (japhb/Terminal-LineEditor#11) I chewed on this one for a while, and examined the code in Terminal-API. Here are my thoughts: 1. I am not at all opposed to the _general_ idea of leaving T-API to handle querying operations in OS-specific ways for the rest of the Terminal-* stack, but I think the decision comes down to the details. 2. I don't see a lot of win when some queries have to go through T-API and some have to go through ANSI VT queries, as long as those ANSI VT queries are supported on all modern terminals. 3. Currently T-API doesn't have a way to query for cursor position, so T-LE has to support ANSI VT querying for now anyway. 4. It's not clear to me if T-LE or T-W will need more advanced terminal queries in the future, but if so that extends the lifetime of item 3. 5. Whatever querying path used, I'd love to get completely away from using subprocesses to run terminal queries, especially since the commands executed are unlikely to be identical across OSen. 6. Until Rakudo supports varargs NativeCall, T-API is stuck using `tput` on POSIX, which violates item 5. So I think on balance I want to keep the current code here for now, but I'm happy to reassess if/when items 2, 3, 4, and 6 are all addressed. Closing for now, feel free to reopen if you think I'm missing something in my analysis. :-)

I fully agree!