Filename completion

[JohnQSmith]

I have a directory of files.

G:\SVN_Backup> dir

 Volume in drive G is LOCAL DISK     Serial number is 17ea:3758
 Directory of  G:\SVN_Backup\*

 2/12/2014  10:27         <DIR>    .
 2/12/2014  10:27         <DIR>    ..
 2/03/2014  17:07         442,142  svn_bash_000000_000001.dump.zip
 2/13/2014  13:47     151,346,003  svn_cf_000000_000261.dump.zip
 1/14/2013  16:37      82,591,740  svn_php_000000_000499.dump.zip
 3/26/2013  08:22       8,637,115  svn_php_000500_000999.dump.zip
 7/19/2013  08:39      47,201,270  svn_php_001000_001499.dump.zip
 9/11/2013  13:59      25,663,297  svn_php_001500_001999.dump.zip
11/13/2013  15:30      48,399,294  svn_php_002000_002499.dump.zip
 2/21/2014  14:25       9,596,660  svn_php_002500_002999.dump.zip
 3/10/2014  09:21       9,003,372  svn_php_003000_003055.dump.zip
 3/19/2014  11:32         223,435  svn_php_003056_003126.dump.zip
 3/25/2014  11:27       4,832,044  svn_php_003127_003150.dump.zip
 3/27/2014  15:02      42,187,995  svn_php_003151_123456.dump
       430,124,367 bytes in 12 files and 2 dirs    430,309,376 bytes allocated
    95,973,867,520 bytes free

I just created file on the bottom of the list while doing an incremental dump of our subversion server. I knew the starting revision, but didn't know what the latest revision would be so I just put in a filler number. After the dump was finished, I found out what the latest revision was and started to rename the file accordingly. However, upon typing the following command...

G:\SVN_Backup> ren *.dump

and pressing the tab key to autocomplete the only "*.dump" file in the directory, it completed with...

G:\SVN_Backup> ren svn_bash_000000_000001.dump.zip

CMD and BASH both don't do this; they correctly expand to "svn_php_003151_123456.dump".

Is there some setting I'm missing?

I checked the help file and the only thing I found that could explain this was...

If you type a filename without an extension, TCC will append * to the name on LFN drives, and *.* on drives which only support short file names. It will also place a * after a partial extension.

The first sentence doesn't apply since I provided an extension and the second sentence should not apply since it was not a partial extension.

 

[Charles Dye]

The first sentence doesn't apply since I provided an extension and the second sentence should not apply since it was not a partial extension.

What exactly is a "partial extension", anyway?

 

[JohnQSmith]

What exactly is a "partial extension", anyway?

I'm guessing if I'd typed something like "ren *.du".

 

[rconn]

WAD - a '*' wildcard is always appended to the end of the filename. This is a (much) requested feature.

The reference in the documentation is a leftover from the FAT days; extensions are largely meaningless since the advent of LFNs, and a '.' has no more relevance than any other character in terms of filename completion.

If the default filename completion behaved the way you expected it to, you would never be able to do tab completion on anything that had more than one '.', unless you manually entered everything yourself (i.e., "*.dump.*"). If you want to truncate the filename completion on the first "extension", you can use a regular expression.

 

[JohnQSmith]

At the very least, it should pick the exact extension first and then cycle through the extended extensions (that's what ZShell does).

extensions are largely meaningless since the advent of LFNs,

And yet .EXE, .BAT, .LNK, .BTM, .etc... files still exist. Not a convincing argument.

Extensions should be parsed from the right, not the left.

 

[rconn]

And yet .EXE, .BAT, .LNK, .BTM, .etc... files still exist. Not a convincing argument.

Those "extensions" mean nothing to the file system or the OS. They're app specific (and handled differently by different apps), which makes for a far less convincing argument that one app (TCC) should know what every other app wants to do with particular extensions.

Extensions should be parsed from the right, not the left.

The current filename completion behavior has been basically unchanged for upwards of 20 years. There is zero chance that the default behavior will be changed -- but if you can get a few hundred votes on the feedback forum in favor of your preference, I'll consider an option to change the default. (Or you could create a plugin with your desired completion behavior.)

 

[Charles Dye]

(Or you could create a plugin with your desired completion behavior.)

In theory you could, but I don't think there are any hooks for intercepting or modifying filename completion. A plugin would have to reimplement ... everything. The whole completion mechanism, from scratch. Months of work.

 

[rconn]

In theory you could, but I don't think there are any hooks for intercepting or modifying filename completion. A plugin would have to reimplement ... everything. The whole completion mechanism, from scratch. Months of work.

Yes, but modifying the existing filename completion to behave differently for different users would be nearly as much (if not more) work. Not to mention the new incompatibility issues for support.

 

[Jay Sage]

I have a completely different approach for dealing with this situation (where file-completion would get to the file eventually but not necessarily quickly or in a way easy to distinguish quickly from other similarly named files).

I have toolbar buttons DESC, EREN, REN, MOVE, and some others. They operate on the file selected in the TCMD window. So in a case like what you describe, I would list the files, using either my DN (directory sorted newest last with one file per line) or LATEST (just the files created in the last few days) or TODAY (just the files created today). Then I would double-click the file name I want to work with to select it and click on the appropriate button (EREN in this case).

The code for my EREN button is

esc "eren %_selected" enter​

The 'esc' at the beginning clears anything that I might have started to type on the command line.