-
Notifications
You must be signed in to change notification settings - Fork 8.3k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WT_WINDOWID available as env variable #17863
Comments
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 Others include...
In general, we've been "offering" |
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. |
FWIW I do have plans to have Otherwise, there's probably something we could do with having |
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 <#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 <#7337>
—
Reply to this email directly, view it on GitHub
<#17863 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAOQV474G7UKPMIECUQBUTZVA3MLAVCNFSM6AAAAABNVKKUJCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZRGI2DCNBTHE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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.
The text was updated successfully, but these errors were encountered: