Never sort current file as most relevant

[lencioni]

When I fire up Command-T, I never want to open the file that I am currently editing. I think it might be nicer to either not include it in the list of files to open, or sort it down by a notch. This often happens if I am editing a file that has a similarly named file, like a spec, and I want to go from the component to the spec or vice versa.

[wincent]

Yeah, keeping it out of the top slot sounds reasonable (arbitrary, but subtle enough not to get annoying). It's possible some people have workflows where they want to re-open the same file in another place (eg. in a tab), but the fact that the file will still be nearby in the list is a mitigating factor, and we could always make it a configurable option if we were worried about it being a workflow-breaking change.

[wincent]

So as a quick experiment I threw together this hacky patch which bumps the current buffer out of the top notch if necessary:

https://gist.github.com/wincent/039b4da304a93a33ae5a

It does feel a bit weird. For example, if I see "A" and "B" at the top of the listing, then open "A", the next time I open it, I see "B" and "A". If I then open "B", the next time I show the listing it again shows "A" and "B".

This made me think of excluding all buffers which are already open, but I can imagine that getting frustrating when you forgot what buffers you have open and discover too late that's why you can't see them in the file listing (and you have to break out and switch to the buffer finder instead).

Perhaps just entirely excluding the current buffer is the least jarring option.

[lencioni]

Thanks for working on this feature reques!

It does feel a bit weird. For example, if I see "A" and "B" at the top of the listing, then open "A", the next time I open it, I see "B" and "A". If I then open "B", the next time I show the listing it again shows "A" and "B".

Although I haven't tried it out yet, this sounds fine to me. I don't usually pay attention to anything but the top listing anyway.

This made me think of excluding all buffers which are already open

This would definitely not work for me. I never think about which buffers I have open when using Command-T.

Perhaps just entirely excluding the current buffer is the least jarring option.

You could always start by implementing it with options for no modification, demotion, or removal so you can test drive them each for a while and see which is best. I imagine the code difference in demotion and removal would be pretty small.

[UrsaDK]

Personally, I think that excluding files from the list leads to confusion: a user knows that the file exists, they type it's path/name into the search, they expect to see it on the list but it's not there. Why? "Because it is already opened" is not an obvious answer, especially if the user navigated to that file via tag jumps and thus hasn't paid much attention to the name of the file they are working in.

Changing the ranking of files based on what the user has opened leads to inconsistent order of items on the list, which doesn't seem to be ideal either.

Maybe the best approach here is to anticipate the user's action and preselect the first unopened file with the highest ranking. If all files on the list are already opened then preselect the first file with the highest ranking which is not shown in the current buffer. And only then, fall back to selecting a file with the highest ranking.

This way, the list of files will remain consistent every time the user opens it, yet the selector/cursor will be placed on a more likely candidate.

It could be an optional setting which would also play nicely with #168 (which, I am not trying to promote here. It's just that the idea of preselecting an item other then the one at the top of the list was already in my head, and it seemed like a good fit here)

What do you think guys?

[wincent]

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¹. Feedback issue for 6.0.x is here:

• 🆕 Command-T 6.0.0 release — compendium issue #393

Footnotes

1. Patches and PRs would be welcome, but my personal efforts are going to be directed towards main. ↩