Yes, the usage is dependent on the workflow. I think I see this problem now more often
because my computer gets older and the file list is really huge
Just to give a little bit more context: I often find myself working in parallel in a few
different files, e.g. up to 10 that I have to edit during a single feature implementation.
Now when I use the CMD-T file listing I don’t necessarily enter any search string, but I
glance at the list and identify the file that I’m looking for by it’s name. So in that
case I would actually expect that the file order has been cached somewhere and the top
results should be determined by my edit history.
If I enter a search text, then I fully understand that the list has to update.
But what I see right now is that the compilation of the file list takes long enough, so
that updates in the file list happen (which creates the scroll issue that I was
describing) even if I don’t enter any search term.
Does that make sense?
I’ll try my luck with disableFilterListAutoScroll.
Am 18.11.2016 um 17:15 schrieb Allan Odgaard
On 18 Nov 2016, at 22:13, Ralf Baumbach wrote:
The scroll issues is a different problem, that I have noticed for a while, at least since
rc.1, just didn’t come around reporting.
I don’t think this has ever worked as you expect.
I introduced a disableFilterListAutoScroll which you can set to YES in rc.4.
I did not make this the default behavior because we generally do want to scroll the
selected item into view once the list is updated (at least when the update is caused by
the user changing the filter string).
Currently there is no way for the code to know what caused the update.
Also, with your workflow, where you scroll before the list has been fully loaded, you
could overlook new items appearing above the visible part of the list.
textmate mailing list
Konzeption und Entwicklung von Web-Applikationen