TabExpansionPlusPlus icon indicating copy to clipboard operation
TabExpansionPlusPlus copied to clipboard

Completion of Arbitrary Native Exe's

Open jhclark opened this issue 9 years ago • 5 comments

My group has a C# library that we use for command line parsing and we have dozens of native exe's that use this same library. It would be easy for us to have an exe dump its parameters using something like "any.exe --DumpCompletionParams", so it would be nice if PowerShell could make use of this -- but without needing to write a specialized wrapper for every exe.

But according to https://github.com/lzybkr/TabExpansionPlusPlus/blob/405c7f8502839615c1d45809d8801de586eb3b74/TabExpansion%2B%2B.psm1#L303, the CommandName parameter is not optional for native exe's.

Is there any workaround, or are we stuck having to enumerate all of the exe's that we'd like to have tab completion for?

(Continuation of https://github.com/lzybkr/PSReadLine/issues/194)

jhclark avatar Jan 27 '15 04:01 jhclark

I was thinking about similar thing: generic approach to dump help for commands (like foo.exe /? and foo.exe -h) and produce tab completion.

vors avatar Jan 27 '15 07:01 vors

PowerShell has a built-in extension point and it requires a command name. The idea was that nobody should need to duplicate the parsing and dispatch logic.

TabExpansion++ just makes it easy to register those completers.

I considered other approaches, but felt that the current approach gave the best in terms of coverage for the effort involved - argument parsing and help output differ greatly in the Windows world, so a common core would be somewhat less useful.

I do accept pull request though - so if you come up with something...

lzybkr avatar Jan 27 '15 16:01 lzybkr

Along the lines of the pull request, back to PSReadLine. :) Am I crazy for wanting to just add a pluggable callback after this line? Any gotchas to look out for? https://github.com/lzybkr/PSReadLine/blob/master/PSReadLine/Completion.cs#L213 Something like: _tabCompletions = PluginCallbackCompleteInput(_buffer.ToString(), prevCompletions: _tabCompletions); PluginCallbackCompleteInput could then call out to the .exe detected in _buffer and ask it what its completions are. Date: Tue, 27 Jan 2015 08:44:18 -0800 From: [email protected] To: [email protected] CC: [email protected] Subject: Re: [TabExpansionPlusPlus] Completion of Arbitrary Native Exe's (#32)

PowerShell has a built-in extension point and it requires a command name. The idea was that nobody should need to duplicate the parsing and dispatch logic.

TabExpansion++ just makes it easy to register those completers.

I considered other approaches, but felt that the current approach gave the best in terms of coverage for the effort involved - argument parsing and help output differ greatly in the Windows world, so a common core would be somewhat less useful.

I do accept pull request though - so if you come up with something...

— Reply to this email directly or view it on GitHub.

                  =

jhclark avatar Jan 28 '15 04:01 jhclark

That's what TabExpansion++ is really all about. And really, what you're suggesting is part of how completion already works in PowerShell - if you define your own TabExpansion2 function, you can call into PowerShell or the replaced implementation of TabExpansion2 if your version doesn't work.

Note that if you roll your own, if you aren't that careful in your implementation, completion will be subtly broken, mostly because people are terrible at parsing/analyzing the command line and forget how complicated it can be. In the common case, stuff will just work, but if people do tricky things on the command line, completion might get messy or do weird things - that's why I introduced the extensibility based on command names.

I've tried to keep the projects separate because completion extensions are useful in other hosts, like the ISE, and PSReadline can't work in the ISE.

There are some notable exceptions - e.g. bash completion or appending a trailing backslash on directories - those cases are involve UI and the completion replacement, so I didn't see a clean way of adding that functionality to TabExpansion++.

lzybkr avatar Jan 28 '15 05:01 lzybkr

Yes, it seems I had overlooked the built-in TabExpansion and TabExpansion2 functions. Based on this article, looks like redefining TabExpansion should do the trick for my use case: http://blogs.msdn.com/b/powershell/archive/2006/04/26/584551.aspx Thanks for helping me navigate around these various hooks.

Date: Tue, 27 Jan 2015 21:21:02 -0800 From: [email protected] To: [email protected] CC: [email protected] Subject: Re: [TabExpansionPlusPlus] Completion of Arbitrary Native Exe's (#32)

That's what TabExpansion++ is really all about. And really, what you're suggesting is part of how completion already works in PowerShell - if you define your own TabExpansion2 function, you can call into PowerShell or the replaced implementation of TabExpansion2 if your version doesn't work.

Note that if you roll your own, if you aren't that careful in your implementation, completion will be subtly broken, mostly because people are terrible at parsing/analyzing the command line and forget how complicated it can be. In the common case, stuff will just work, but if people do tricky things on the command line, completion might get messy or do weird things - that's why I introduced the extensibility based on command names.

I've tried to keep the projects separate because completion extensions are useful in other hosts, like the ISE, and PSReadline can't work in the ISE.

There are some notable exceptions - e.g. bash completion or appending a trailing backslash on directories - those cases are involve UI and the completion replacement, so I didn't see a clean way of adding that functionality to TabExpansion++.

— Reply to this email directly or view it on GitHub.

                  =

jhclark avatar Jan 28 '15 05:01 jhclark