Tab completion annoyances

Aug 16, 2008
124
0
That is apparently your usage. It is not mine (or apparently most other users).

[...] If you know you've only got one app on your entire system with a given name (unlikely, but it's possible for a small system), why do you need command completion in the first place? To save a character or two? You're better off defining an alias; it'll be a lot faster and you won't get an unpleasant surprise when the inevitable second app of the same name appears on your system.

Well, Take Command users seem to be a strange breed with needs that no one else shares. The whole Wikipedia article about completion focuses on "require fewer keystrokes to reach" and doesn't even mention the "multiple commands with the same name" use case.

http://en.wikipedia.org/wiki/Tab_completion
 
Feb 23, 2012
240
3
Well, Take Command users seem to be a strange breed with needs that no one else shares.

Thorsten,

Take Command is a brilliant piece of user-driven software that excels precisely because it does not subjugate itself to the inferior norms of other shells.

I've personally merited seeing several of my ideas implemented in TC, and many other users have as well. I'd venture that you cannot say the same for Powershell.

The fact that other shells work one way or another is not, and should not be, a factor in determining how Take Command should work. The wonderful part about TC is that the primary factor in its development is what the users would find useful - rather than simply duplicating the less useful paradigms of Powershell and other shells.

We've all chosen to pay for TC, rather than to use the free Powershell, because at the end of the day TC affords a much higher gain in productivity - because it's been designed for real users and real user patterns. If anything, it's Powershell that caters to a "strange breed" (have you ever tried to filter output by regex in Powershell?)

And, at the end of the day, Rex happily agreed to provide the options you want, given enough demand, once again demonstrating that TC develops to meet the real needs of real users. So please stop bashing TC for not being like bash!
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
4,594
97
Albuquerque, NM
prospero.unm.edu
Sorry, but this is getting ridiculous

Thorsten:

Did you know that you can turn path completion off? It seems that you don't like the way it works. I have no use for it myself; it seems like a totally pointless feature to me. So: type OPTION and hit Enter, select the "Command Line" tab, turn off the "Search PATH" tick box, and press Enter.

Gone!
 
Aug 16, 2008
124
0
Thorsten:

Did you know that you can turn path completion off? It seems that you don't like the way it works.

Well, command completion from path done right can be pretty useful. Right now, when I press nir<TAB>, I get "F:\program files\take command\..\..\cygwin\usr\local\bin\nircmd.exe" which somehow violates my "personal aesthetic preference".
 
Aug 16, 2008
124
0
Thorsten,
The fact that other shells work one way or another is not, and should not be, a factor in determining how Take Command should work.
[...]
So please stop bashing TC for not being like bash!

Needless to say that I didn't do that. My mentioning of how completion works in other shells was to counter the constant "oh, you want 'fire' to complete to 'firefox'?! Now that is strange, I never heard of that and certainly no one has ever requested that" argument. It's sometimes good to make yourself aware that users in other shells have the same needs and they apparently don't have dozens of executables on their path with the same name.

This whole thread was kind of interesting because it showed some kind of disconnect between at least some users of Take Command and modern shell usage. Rex' "If you know you've only got one app on your entire system with a given name [...], why do you need command completion in the first place?" was extremely revealing in that regard. Tab completion in modern shells is not just merely saving yourself some keystrokes. It's a whole new paradigm:

Modern shells have extended this basic idea well beyond its original scope. All manner of
things can be completed: filenames, usernames,options, email addresses, words taken from
the shell history, and anything else you can possibly imagine. When multiple completion candiidates exist, the list of possibilities can be displayed, accompanied by descriptive explanations,
and an interactive menu can be used to select among the possibilities. Also, it doesn’t stop at
merely completing extra characters: anything that involves intelligently interpreting your
current command line to do something usefulcan be done—correcting typos and expanding
patterns, for example.

Modern usage is that you actually tab complete EVERYTHING. You constantly press the tab key and the shell shows you what it expects from you and gives you information how to proceed.

But tab completion in Take Command is just patch work at best. You don't even have completion for the most basic of things like internal commands. Some advanced things like menu selection have been implemented but in such a way (via GUI popup) that it stalls your shell if you ever try this via SSH. Most commands have "command dialogs" (again implemented via a GUI) which again will break if you would ever try this via ssh and looks simply weird otherwise when you constantly jump between command line and GUI.

The above things are not just gimmicks. Tab completion is the one main productivity booster in shells. It's a constant "if in doubt, press the tab key". A consistent completion system designed from the ground (in conjunction with programmable completion) would be actually something that would really make a difference and justify "just a another upgrade". Right now we have a yearly or so "upgrade to version x+1, I implemented some new commands" kind of "evolution".
 
Apr 15, 2013
7
0
I just stumbled over this thread and must say that I totally agree with Thorsten. I've used TCC and its predecessors for a long time and am pretty satisfied with it. However, I always wished there were an option to disable this annoying behavior of adding paths and filename suffixes when using the TAB completion for commands. The full filename expansion of commands is completely useless to me and only floods the command-line with unnecessary stuff. Of course, the current completion paradigm might be useful for a lot of users, but if you come from a Linux context with powerful shell completion functionality, you wished there were a similar mechanism in TCC. Defining aliases isn't a real alternative to work around the recent behavior. So I would wholeheartedly vote for an option that prevents the addition of paths and suffixes to commands.
 
Sep 29, 2014
21
0
Again, add it to the feedback forum to see if anybody else wants the same thing.

I would vote right now, if I find my way to it!

I have quite a hand full of batch files now, and all of them use unique names, and it is distracting to see the whole path for me. I'm like "whoa, what? What am I running? C:\User\... oh, I'm running my batch file, correct!"

But that is why everybody else wants the path to be included -- it's a feature, not a bug. People want to know what they're executing; if you don't care, there's no reason to use command completion.

You want to remove functionality that other users rely on, for the sake of a personal aesthetic preference (and apparently a desire to be surprised by what the command processor decides to execute). That will never be the default behavior -- but if you get enough users to vote on your preference, I will consider adding it as an option.

I have personally no problem of what others wants, and would never in the world would like to make TCC more difficult for others just to make it more to my liking, but if I specify how such feature would work, or would be used, would it be considered to include at least an option for it?
Because perhaps a reasonable command completion would be / could be (or what I would expect, and perhaps the original poster would expect to my understanging), for example, "pin<tab>" expands to "ping" or rather "ping.exe", and when one starts the command this way, the first executable file is executed, that can be found, first in the current directory (or perhaps that also controlled by an option), then the first directory listed in the PATH environment variable, that have such executable file. So if PATH is "[...];C:\ExternalPingProgram\;[...]" and "ExternalPingProgram" folder is the first folder in the list, that holds a Ping.exe, then that is what will be run. If there was no "ping.*" executable file in the current path or on the PATH list, then it wouldn't expand to "ping.exe", rather the next match, like "pingus.exe" as it currently does so of course. On the other hand, if when TCC executing a command TCC does not decides which command to run, then the whole thing can be specified by the behavior of the system.
I only find this a surprising behavior if one is not aware of what the PATH environment variable holds, and sometimes I do not know it either, but, considering, that ideally it is never queried in such way, I quite often check it's content with:
Code:
for /t";" %i in (%path%) echo %i

On the other hand, if a user want to know which command will be executed by typing in something, wouldn't one use, or could use the WHICH internal command? Still don't want to remove an old feature, especially if it was demanded, but command completion without paths, with conjunction of the WHICH command seems a rather sensible setup to me.

AND perhaps there could be a hybrid mode, where it first expands to first, simply to "ping.exe" and/or "pingus.exe", then starts to cycle through the executable files with full path name. (The order of what it expands to could be what is more reasonable to do -- ATM I don't have any preference on that, just dropped in this idea that popped in to my head as I was writing.)

PS.: It is more than clear, that debating on whether it is a meaningful feature does not necessarily make a change in the product, but then again I do not know where can I vote for this feature, and in the mean time, I thought I share my thoughts of it as well. Or perhaps this feedback forum is not here, within these forums, but rather is the http://jpsoft.uservoice.com/forums/94009-take-command site? Is this the main page? I might as well browse that site, to find if there is already a suggestion there.
 
Jan 11, 2022
20
1
This is something that didn't get along with my workflow too well either, so I wrote a TABCOMPLETE script to provide alternate behavior (of completing just the filename).

The documentation is at the top of the HTML conversion:

~/Temp/tabcomplete-command.btm.html

and the script itself in plaintext is here:

https://www.illcode.com/serve/tabcomplete-command.btm

To summarize from the docs:

The way it works is that when entering a command it checks if what you've typed so far begins or ends with a sigil string (by default '#'), and if so, it will complete the command (with the sigil removed) to the first matching item on your PATH *without* the full path name.

For example, #pin<TAB> (or pin#<TAB>) will be completed to PING.EXE, not to C:\Windows\system32\PING.EXE as would TCC's normal tab-completion.

There's other configuration options and behaviors, explained in the docs.

~Jesse
 

Similar threads