18 Nov
2016
18 Nov
'16
1:59 p.m.
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
18 Nov
18 Nov
2:12 p.m.
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.
2:45 p.m.
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(a)textmate.org>rg>:
On 18 Nov 2016, at 20:59, Jonathan Monahan wrote:
--
Web-Entwickler
Konzeption und Entwicklung von Web-Applikationen
ralf.baumbach(a)mailbox.org
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(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate
3 p.m.
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.
3:13 p.m.
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(a)textmate.org>rg>:
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(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate
--
Web-Entwickler
Konzeption und Entwicklung von Web-Applikationen
ralf.baumbach(a)mailbox.org
4:15 p.m.
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.
5:42 p.m.
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(a)textmate.org>rg>:
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(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate
--
Web-Entwickler
Konzeption und Entwicklung von Web-Applikationen
ralf.baumbach(a)mailbox.org
1635
days inactive
1635
days old
6 comments
3 participants
participants (3)
-
Allan Odgaard -
Jonathan Monahan -
Ralf Baumbach