WT_WINDOWID available as env variable

[cavanaug]

Description of the new feature/enhancement

Add WT_WINDOWID to the client environment that has the window id for that Windows Terminal Instance.

I would like to make some calls to wt.exe to automate things, but it is a giant pain in the backside to try to figure out the WindowId. Perhaps Im missing something but we already have WT_PROFILE_ID & WT_SESSION available in the environment. Why not the WindowId which would be really useful for any automation calls to wt.exe?

Or perhaps there is an easier way to do this that I am missing??

Proposed technical implementation details (optional)

Pass a new WT_WINDOWID to the WSL environment to allow for automation scripts to call wt.exe specifying the window.

[DHowett]

There's a few blockers here. The main one is that we can't update the process's environment after it's been spawned (especially not in the case of WSL), so when you move a tab between windows such an identifier would immediately fall out of sync. That's solvable (for example, maybe we should let you say "I want the window hosting session aaaaaaaa-bbbb..."?)

Others include...

• We need to complete work on the console client side to let us inject things (including WT_SESSION!) into newly-launched processes, so that apps launched into Terminal via the "Default Terminal" setting get the same tracking info (#13006)
• Those environment variables would be inherited, so launching e.g. VS Code from Terminal may result in subprocesses in VSC targeting Terminal windows that they share no ancestry with.

In general, we've been "offering" -w 0 as shorthand for the most recently used window. It's not ideal if you have things running happily along in the background, though, I will admit.

[cavanaug]

Ah, I didnt consider some of those use cases. Would it be possible to have a command line option for wt.exe (or perhaps something similar) that given a WT_SESSION it would return the WT_WINDOWID? That way you could more easily map to WindowId?

I guess to truly do this in a dynamic fashion inside of WSL you would need some type of synthetic device and driver. That Im sure is a non-trivial effort.

[zadjii-msft]

FWIW I do have plans to have -w 0 do The Smart Thing, and figure out the right window ID based on the current WT_SESSION_ID. That's tracked over in #10561. Would that work for your use case/?

Otherwise, there's probably something we could do with having wt.exe write out windows,tabs,panes,session_ids straight to stdout, now that we're post-#7337

[cavanaug]

Assuming it works from WSL calling wt.exe directly and the ENV from WSL is available in wt.exe that would work... But I think still have wt.exe write out panes etc is still a good idea as a capability. Im thinking scenarios like neovim and getting smarter about splits/panes between windows terminal similar to what is possible with tmux.

On Thu, Sep 5, 2024 at 4:06 AM Mike Griese @.***> wrote:

FWIW I do have plans to have -w 0 do The Smart Thing, and figure out the right window ID based on the current WT_SESSION_ID. That's tracked over in #10561 https://github.com/microsoft/terminal/issues/10561. Would that work for your use case/?

Otherwise, there's probably something we could do with having wt.exe write out windows,tabs,panes,session_ids straight to stdout, now that we're post-#7337 https://github.com/microsoft/terminal/pull/7337

— Reply to this email directly, view it on GitHub https://github.com/microsoft/terminal/issues/17863#issuecomment-2331241439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOQV474G7UKPMIECUQBUTZVA3MLAVCNFSM6AAAAABNVKKUJCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZRGI2DCNBTHE . You are receiving this because you authored the thread.Message ID: @.***>