Skip to content
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

Extension: Pipe output to command palette in Terminal #8797

Open
zadjii-msft opened this issue Jan 15, 2021 · 7 comments
Open

Extension: Pipe output to command palette in Terminal #8797

zadjii-msft opened this issue Jan 15, 2021 · 7 comments
Labels
Area-CmdPal Command Palette issues and features Area-Commandline wt.exe's commandline arguments Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal.
Milestone

Comments

@zadjii-msft
Copy link
Member

Okay, this is gonna sound crazy so bear with me. I was switching git branches, and thought, "I really do not know how to use less well, and git branch | $ grep foo each time is annoying".

Then I thought, we've got this great command palette for filtering a list of things.

As an extension, what if we could pipe a list of items to the terminal, and then have the terminal open up the command palette with those items populated in it. Then selecting one of those items would insert that text?

So something like:

git branch | wt -w 0 select-list --prefix "git checkout "

would pipe to the current window, into the command palette. --prefix "git checkout " would indicate "use this text as a prefix for whatever the selected item was".

So hitting enter on one of these items, like "dev/migrie/foo" would SendInput git checkout dev/migrie/foo to the terminal.

This encapsulates a bunch of things:

  • extensions need to be able to add their own subcommands to the commandline parser
    • they also need to be able to parse their own args
  • extensions need to be able to open a command palette FilterableListView with whatever they want (a set of actions in this case. The actions would all be {sendInput(prefix+item), name=item})
@zadjii-msft zadjii-msft added Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Product-Terminal The new Windows Terminal. Area-Commandline wt.exe's commandline arguments Area-CmdPal Command Palette issues and features labels Jan 15, 2021
@zadjii-msft zadjii-msft added this to the Terminal Backlog milestone Jan 15, 2021
@ghost ghost added the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Jan 15, 2021
@DHowett

This comment has been minimized.

@DHowett DHowett removed the Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting label Jan 28, 2021
@zadjii-msft
Copy link
Member Author

zadjii-msft commented Jul 29, 2021

~Hokay so it's not this simple. wt is a WINDOWS subsystem application, so even when it is piped to, we can't GetStdHandle(STD_IN)/ReadFile the input piped to it.

We'd need the proposed wtc as a helper here. wtc select-list could check if there's input piped to it, and then use the Remoting lib to pass that to the monarch to pass to the active window...~

WAIT what

windowsterminal.exe, when running unpackaged, accepts input from the commandline perfectly fine. But wt doesn't? Is this because there's the wt.exe shim in the middle that's not passing the input through to windowsterminal.exe? Oh it might be...

EDIT:

It definitely was that. If you change the wt.exe shim to bInheritHandles=true, then this works just fine.

@zadjii-msft
Copy link
Member Author

hackathon week is my favorite week

select-list-000

zadjii-msft added a commit that referenced this issue Jul 29, 2021
  This is basically the complete #8797.
@zadjii-msft
Copy link
Member Author

Remaining TODOS:

  • generic todos throughout code - resources, etc.
  • after selecting/dismissing this menu, return to the normal list of commands in the palette. Right now it leaves them behind!
  • Maybe don't overload the Command ctor like I did?
  • add a -t,--trim parameter, to remove whitespace on either side of the command
  • add short form, sl (?)
  • If select-list is the only action, and -w wasn't provided, then default to -w 0, and DONT ADD new-tab. So dir | wt sl will by default run in the current terminal
  • add a --suffix arg as well
  • Ignore empty lines entirely.
  • trim \rs off too. Don't want to be executing these things immediately!
    • maybe add a commandline arg to append the enter so the user can just execute immediately?
  • --icon to set an icon for the commands? That seems wack though. If only we could font-fallback to nerd-fonts for their git symbol.
  • Make sure that this can't actually get parsed by json. Or should it?
  • Should wt sl --option "foo" --option "bar" etc work as expected? Like, should we actually allow that param on the commandline, and only use Stdin when it's actually there? (When would this be useful...?)
    • wt sl -o cmd -o wsl -o pwsh --prefix "wt -w 0 nt"? something like that?

<unbelievably wack idea>

sendInput("dir /b /ad | wt sl --prefix cd") bound to a key is fun. Maybe next year I'll think of a way to auto-bind that as a nested command, so you can navigate your directory tree with the command palette lol.

Maybe that would work as a combo with #9994 and #5970

{
  "command": {
    "action": "executeActions",
    "subcommand": "cd",
    "actions": [
	  { "action":"sendInput", "input": "dir /b /ad | wt sl --prefix cd --suffix \"; wt cd\"\n"}
	]
  },
  "name": "change directory..."
},

so that would cause wt cd to input dir /b /ad | wt sl --prefix cd --suffix "; wt cd"\n to the terminal. We'd open up the command palette with the list of directories, and upon selecting one, we'd navigate to that directory, and immediately do another wt cd, bringing up the menu again. Hitting esc would dismiss this palette.

@cpriest
Copy link

cpriest commented Jul 30, 2021

Just a thought on this. fzf already does this very well and works everywhere.

@zadjii-msft
Copy link
Member Author

@cpriest Yea, I was mostly just messing around with this to see if this particular combination of things would work directly in the Terminal. It was more of an experiment than anything else. Almost more as a thought experiment more than anything else, but having the actual prototype in front of me was fun to play with and see what else we could do with something similar.

@zadjii-msft
Copy link
Member Author

As a possibly related combination of wack ideas:

AS mentioned in #4719

Another really useful plugin would be a Text Editor that could be used for profiles and scripts. The data would be piped to/from the Console for reading and saving

wack idea:

type foo.txt | wt open-scratch

where open-scratch will read from stdin.

Though, it does seem easier to just

wt edit foo.txt

This all might be fully impossible with the new process model v3 as of 1.18. The wt that's run is a different process than the current one, so it'd be hard to plumb the HANDLE to the right place...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-CmdPal Command Palette issues and features Area-Commandline wt.exe's commandline arguments Area-Extensibility A feature that would ideally be fulfilled by us having an extension model. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Product-Terminal The new Windows Terminal.
Projects
None yet
Development

No branches or pull requests

4 participants
@cpriest @DHowett @zadjii-msft and others