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 mailinglist@textmate.org:
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 textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
-- Web-Entwickler Konzeption und Entwicklung von Web-Applikationen ralf.baumbach@mailbox.org