command-t
command-t copied to clipboard
wincent
last files history and file creation
I have been using vim forever. Today i tried Zed editor just out of curiosity. I think it has a couple of ideas that could be interesting here so i try to explain them.
When user hits command-t, before it has typed anything to look for, it would be nice to show a history of the last files that have been opened using command-t with the last ones on top. This allows jumping to "one of those files i was editing before" without remembering the name.
If the user looks for for a specific path that does not match any file, it would be nice to actually create the file just by typing enter (i.e. command-t: this/specific/path/newfile.txt). The list of results would have no items but a hint showing "no matches found, type enter to create new file.."
What do you think ?
If the user looks for for a specific path that does not match any file, it would be nice to actually create the file just by typing enter (i.e. command-t: this/specific/path/newfile.txt). The list of results would have no items but a hint showing "no matches found, type enter to create new file.."
I often create files outside of vim as bash completion and cd make it much easier than :e within vim. I think it would be useful if one could still auto complete a folder. Say, special command opens usual command-t completion, but only with folders, and after the user clicks enter, she is being asked to provide a filename and the file with the specified filename is created within the selected folder. Extra bonus if this operation automatically flushes the cache :)
I disagree with the idea of having a separate special command for this. Bash-style tab-based completion could be nice in general while writing in command-t search box and it could be yet another feature request.
When user hits command-t, before it has typed anything to look for, it would be nice to show a history of the last files that have been opened using command-t with the last ones on top. This allows jumping to "one of those files i was editing before" without remembering the name.
The devil is in the details here. This sounds like a nice idea on the surface, but what does "allows jumping" mean? (ie. how does the user select one of the files from the list?) If it's using the cursor keys, fine, but if it's by typing letters from the path as in normal Command-T usage, should it initiate a full search (I'd think it should) and at that point how should we handle the display of the search results from the file system and those from the recent file list? Should they be merged? Is there actually a hidden additional feature request here to boost recently-opened files in the search results listing? Can you get 90% of the way there with the buffer finder (:CommandTBuffer)?
If the user looks for for a specific path that does not match any file, it would be nice to actually create the file just by typing enter (i.e. command-t: this/specific/path/newfile.txt). The list of results would have no items but a hint showing "no matches found, type enter to create new file.."
This one seems to be somewhat simpler, although I am not sure it's the right way to solve this problem. A tool like vim-easydir is made for this scenario, and there's some value in keeping the scope of Command-T narrow (UNIX philosophy, lots of small tools that do one thing well).
Bash-style tab-based completion could be nice in general while writing in command-t search box and it could be yet another feature request.
Could be useful, but tab completion flies in the face of Command-T's fuzzy finding philosophy. Tab completion is about making it easy to precisely specify something, while fuzzy finding is explicitly about getting the job down with precise specification.
(Not trying to shut down the discussion of any of these proposals; just sharing my initial thoughts.)
I try to answer in order. Yes it would be nice to boost results by recent usage but i realise it can be problematic. Maybe even showing the last opened files and then switching to normal search results once user starts typing is good enough. If you think about it, having a random list of files (not sure which logic its following) when the user has not typed anything is less useful than having the history anyway.
There are probably other plugins covering some of these features but i think there is value in the unification of those concepts proposed by zed as a single and comprehensive navigation logic. I think if you read the ZED home page and try to use it, it could give you a better sense compared to what i can do with my poor english :) I see the point of having separation of concerns an minimal design but at some point even separate things should integrate creating one user experience. In this case leaving integration to the user is painful. Maybe command-T is not the right place to do all this, but it felt like a good place to start discussing.
Tab completion for dirs would be only triggered if there is an exact match between the path the user is searching for and the filesystem, starting from cwd. Fuzzy finder would keep working as-is and if the user does not want to autocomplete he just avoids pressing tab.
I am trying something here to see how i feel about it.
https://github.com/davibe/command-t/commits/master
What do you think about the MRU updated on bufwinenter ?
If you think about it, having a random list of files (not sure which logic its following) when the user has not typed anything is less useful than having the history anyway.
The order isn't random; it's alphabetically sorted.
Maybe even showing the last opened files and then switching to normal search results once user starts typing is good enough.
This is a decent idea, although I am concerned about the semantics switching out in the middle of an interaction. For example, when a new Vim session is started, the MRU list is empty, so opening the Command-T prompt will show an empty listing containing only -- NO MATCHES --, which is likely to confuse people. Even once the MRU list is populated, I will see a list of files in MRU order, and after a single keypress, I will see (quite possibly) entirely different files and almost certainly in a different order. Again, I think this could be pretty confusing.
If Vim were a point-and-click IDE it would be possible to combine different search views into one unified UI (something like Nuclide's "Omni-Search" described here) but given its use in a terminal environment, we need something that works well there.
I'm certainly open to ideas on how to make this work, but I don't want to rush into anything that we'll end up regretting later.
For example, when a new Vim session is started, the MRU list is empty
Maybe a few MRU spot followed by current directory or normal alphabetical order ? If there's less MRU than reserved spot, show what we have.
Even once the MRU list is populated, I will see a list of files in MRU order, and after a single keypress, I will see (quite possibly) entirely different files. [...] I think this could be pretty confusing.
Isn't this already the case when we switch from alphabetical order to filtered score ?
Maybe even showing the last opened files and then switching to normal search results once user starts typing is good enough.
I'm pretty sure if the top spot is folder/folder/file and the user type fi and all user see is somthingelse/file, someone is going to be confused.
Even once the MRU list is populated, I will see a list of files in MRU order, and after a single keypress, I will see (quite possibly) entirely different files. [...] I think this could be pretty confusing.
Isn't this already the case when we switch from alphabetical order to filtered score ?
Technically not, because the algorithm is always the same: sort by score, and use alphabetical ordering to break ties. This means that when you start your search and have an empty search string, all files have the same score and the ordering is dominated by alphabetical sorting. So, it might look like it's suddenly switching algorithms but it's actually allows doing exactly the same thing.
By that logic giving a score bonus to MRU at all time would provide a 'technically' consistent interface.
Yep, and I think that would make some sense.
There's a related ticket on the old issue tracker about boosting frequently (but not necessarily recently) opened files, which I also think makes sense.
Ok some tough on the idea.
I believe frequency count can be hard to track, a lot of file can have a low frequency. MRU is a fixed size list. Also frequency may need a "seasonal" interpretation. Maybe one can switch from one project to another and not be interested in previously frequent file.
With that in mind I propose the following: Score bonus using frequency among recent files. IE have a MRU list of size about 100, and for each item of that list, a frequency count. When a item drop off the MRU, frequency count is forgotten.
If needed, only top K items on the MRU list can have a bonus - that would decouple memory effect from bonus effect. We could have a MRU list where first half is active bonus, second half is inactive - but not forgotten, and third half (out of list) is forgotten.
If we need more importance to recency we may do something like a recency weighted frequency.
score = count * 50/(50 + MRUpos)
The frequency would be weighted by the age of the file, measured by the position on MRU list. The weight function has the following behavior:
- Function is steep near the start: recency is important for very recent file.
- Function is flat at large position: among older file, recency is less important.
- Function is 1 at position 0
- Function is 1/2 at position 50, change 50 for anything you need.
An alternative way to mix those two information is exponential forgetting. Active file count+=1.0 every other file count*=0.986 or something like that. This would allow the frequency count to decrease without being completely forgiven.
Those small penalty compound. That number is chosen such that after 50 generation we have score *= (0.986^50) -> score *= 0.49. That is the count that file had will be halved.
Given the big rewrite for v6.0.x, I'm closing all older issues as there is unlikely to be anything significant happening on the 5-x-devel branch from here on[^patches]. Feedback issue for 6.0.x is here:
- https://github.com/wincent/command-t/issues/393
[^patches]: Patches and PRs would be welcome, but my personal efforts are going to be directed towards main.