Hi, Congratulations on reaching the significant milestone of RC1 on Textmate2. Unfortunately a bug has crept in in this release.
In the attached video, I press Cmd+T followed by Enter to switch between the current and previous files. The first time, I wait for the list to appear before pressing Enter, and it works as expected. The 2nd, 3rd and 4th times I quickly press Cmd+T followed by Enter before the list appears – the dialog closes but the previous file is not loaded. On the 5th time, I wait before pressing Enter again, and it works.
Clearly the problem is probably caused by the number of files. Prior to RC1, the list appeared instantaneously, but additional files filled in the list later. Is it possible to go back to that behaviour which has worked well for many years?
Regards, Jonathan Monahan
On 18 Nov 2016, at 20:59, Jonathan Monahan wrote:
Clearly the problem is probably caused by the number of files. Prior to RC1, the list appeared instantaneously, but additional files filled in the list later. Is it possible to go back to that behaviour which has worked well for many years?
Try holding option and select TextMate → Check for Test Builds.
In rc.3 the main thread is stalled until the list has updated with the currently open files, which was indirectly the case prior to rc.1, so rc.1 actually should load files slightly faster than before, but because there was no stalling of main thread, it was possible to press return before the main thread had updated the table with the open files.
Hi,
I’m seeing the same problem. With rc.3 the loading of the list content is better, but there is another behavior that starts driving me crazy: When the window opens and the list loads, it will jump back to the top of the list whenever the list gets updated. So opening the list, start scrolling quickly to the file a little further down the list, want to select, and then often, almost always, the list gets updated and the window jumps back to the top. I just see this problem in the latest releases, but that might be due to the fact that I have a lot more files in my project right now (already excluded some, but the number is still around 9000).
best regards, Ralf
Am 18.11.2016 um 15:12 schrieb Allan Odgaard mailinglist@textmate.org:
On 18 Nov 2016, at 20:59, Jonathan Monahan wrote:
Clearly the problem is probably caused by the number of files. Prior to RC1, the list appeared instantaneously, but additional files filled in the list later. Is it possible to go back to that behaviour which has worked well for many years?
Try holding option and select TextMate → Check for Test Builds.
In rc.3 the main thread is stalled until the list has updated with the currently open files, which was indirectly the case prior to rc.1, so rc.1 actually should load files slightly faster than before, but because there was no stalling of main thread, it was possible to press return before the main thread had updated the table with the open files.
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
On 18 Nov 2016, at 21:45, Ralf Baumbach wrote:
I’m seeing the same problem. With rc.3 the loading of the list content is better, but there is another behavior that starts driving me crazy […]
Just to be sure, you are *not* seeing the ⌘T + ↩ issue with rc.3, but you are seeing *another* issue (that the selected row is scrolled into the visible view each time the list refreshes), correct?
I’ll try to get the scroll issue sorted out for rc.4.
yes, confirmed, the enter issue is fixed on my side with rc.3 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.
Am 18.11.2016 um 16:00 schrieb Allan Odgaard mailinglist@textmate.org:
On 18 Nov 2016, at 21:45, Ralf Baumbach wrote:
I’m seeing the same problem. With rc.3 the loading of the list content is better, but there is another behavior that starts driving me crazy […]
Just to be sure, you are not seeing the ⌘T + ↩ issue with rc.3, but you are seeing another issue (that the selected row is scrolled into the visible view each time the list refreshes), correct?
I’ll try to get the scroll issue sorted out for rc.4.
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
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.
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
-
Allan Odgaard -
Jonathan Monahan -
Ralf Baumbach