I created an issue for this in github.com/textmate/bugs (https://github.com/textmate/bugs/issues/33), but perhaps that issue tracker isn’t monitored any longer.
After upgrading to MacOS 10.15 (Catalina), scrolling through a large file (>6000 lines) often does not properly paint the text. This can be temporarily corrected by dragging a selection over the missing text.
• OS version: MacOS 10.15 (Catalina) • Textmate version: 2019-09-15 (v2.0) • Affected file: https://github.com/w3c/json-ld-api/blob/master/index.html. • File language: HTML Most recently, I noticed this when moving to line 3500 in the referenced file and scrolling downwards.
Gregg Kellogg gregg@greggkellogg.net
This is similar to and possibly the same as the issue I posted about TM not loading the whole file. I’m back at an earlier version because 2.0 is unusable for me. m.
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 13! http://shop.oreilly.com/product/0636920310075.do iOS 13 Fundamentals! http://shop.oreilly.com/product/0636920310068.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
On Oct 10, 2019, at 1:36 PM, Gregg Kellogg gregg@greggkellogg.net wrote:
I created an issue for this in github.com/textmate/bugs (https://github.com/textmate/bugs/issues/33), but perhaps that issue tracker isn’t monitored any longer.
After upgrading to MacOS 10.15 (Catalina), scrolling through a large file (>6000 lines) often does not properly paint the text. This can be temporarily corrected by dragging a selection over the missing text.
• OS version: MacOS 10.15 (Catalina) • Textmate version: 2019-09-15 (v2.0) • Affected file: https://github.com/w3c/json-ld-api/blob/master/index.html. • File language: HTML Most recently, I noticed this when moving to line 3500 in the referenced file and scrolling downwards.
<66504777-c39aed00-ea7e-11e9-996f-261ecbee4a76.png>
Gregg Kellogg gregg@greggkellogg.net
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
TextMate has always had problems with large files since the move to TextMate 2. I think the text rendering is implemented differently compared to TextMate 1.5.
On 10 Oct 2019, at 22:34, Gregg Kellogg gregg@greggkellogg.net wrote:
I created an issue for this in github.com/textmate/bugs http://github.com/textmate/bugs (https://github.com/textmate/bugs/issues/33 https://github.com/textmate/bugs/issues/33), but perhaps that issue tracker isn’t monitored any longer.
After upgrading to MacOS 10.15 (Catalina), scrolling through a large file (>6000 lines) often does not properly paint the text. This can be temporarily corrected by dragging a selection over the missing text.
• OS version: MacOS 10.15 (Catalina) • Textmate version: 2019-09-15 (v2.0) • Affected file: https://github.com/w3c/json-ld-api/blob/master/index.html https://github.com/w3c/json-ld-api/blob/master/index.html. • File language: HTML Most recently, I noticed this when moving to line 3500 in the referenced file and scrolling downwards.
<66504777-c39aed00-ea7e-11e9-996f-261ecbee4a76.png> Gregg Kellogg gregg@greggkellogg.net mailto:gregg@greggkellogg.net
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
On Oct 11, 2019, at 12:02 AM, Jacob Carlborg doob@me.com wrote:
TextMate has always had problems with large files since the move to TextMate 2. I think the text rendering is implemented differently compared to TextMate 1.5.
I had no problems prior to upgrading to Catalina.
Gregg
On 10 Oct 2019, at 22:34, Gregg Kellogg gregg@greggkellogg.net wrote:
I created an issue for this in github.com/textmate/bugs (https://github.com/textmate/bugs/issues/33), but perhaps that issue tracker isn’t monitored any longer.
After upgrading to MacOS 10.15 (Catalina), scrolling through a large file (>6000 lines) often does not properly paint the text. This can be temporarily corrected by dragging a selection over the missing text.
• OS version: MacOS 10.15 (Catalina) • Textmate version: 2019-09-15 (v2.0) • Affected file: https://github.com/w3c/json-ld-api/blob/master/index.html. • File language: HTML Most recently, I noticed this when moving to line 3500 in the referenced file and scrolling downwards.
<66504777-c39aed00-ea7e-11e9-996f-261ecbee4a76.png> Gregg Kellogg gregg@greggkellogg.net
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
-- /Jacob Carlborg
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
I had this conversation with Allan last year. Probably related. Happens mostly with large files too.
On Nov 13, 2018, at 11:19 PM, Allan Odgaard <mailinglist@textmate.org mailto:mailinglist@textmate.org> wrote: On 13 Nov 2018, at 0:04, Ed Wong wrote:
When I move between tabs (either by clicking on tab or using Option-Command left, right arrows) sometimes the page scrolls up by 1 to 3-4 lines each time. But once it does this scrolling then it will do so every time I come back to that tab.
The problem is that it stores a buffer offset as the “first character” but this may visually change due to delayed softwrap calculation.
It’s not a new issue: Once I get around to overhaul the text layout/rendering code, I expect to address this and other related issues.
- Ed
On Oct 11, 2019, at 8:24 AM, Gregg Kellogg gregg@greggkellogg.net wrote:
On Oct 11, 2019, at 12:02 AM, Jacob Carlborg doob@me.com wrote:
TextMate has always had problems with large files since the move to TextMate 2. I think the text rendering is implemented differently compared to TextMate 1.5.
I had no problems prior to upgrading to Catalina.
Gregg
On 10 Oct 2019, at 22:34, Gregg Kellogg <gregg@greggkellogg.net mailto:gregg@greggkellogg.net> wrote:
I created an issue for this in github.com/textmate/bugs http://github.com/textmate/bugs (https://github.com/textmate/bugs/issues/33 https://github.com/textmate/bugs/issues/33), but perhaps that issue tracker isn’t monitored any longer.
After upgrading to MacOS 10.15 (Catalina), scrolling through a large file (>6000 lines) often does not properly paint the text. This can be temporarily corrected by dragging a selection over the missing text.
• OS version: MacOS 10.15 (Catalina) • Textmate version: 2019-09-15 (v2.0) • Affected file: https://github.com/w3c/json-ld-api/blob/master/index.html https://github.com/w3c/json-ld-api/blob/master/index.html. • File language: HTML Most recently, I noticed this when moving to line 3500 in the referenced file and scrolling downwards.
<66504777-c39aed00-ea7e-11e9-996f-261ecbee4a76.png> Gregg Kellogg gregg@greggkellogg.net mailto:gregg@greggkellogg.net
TextMate mailing list TextMate@lists.macromates.com mailto:TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
-- /Jacob Carlborg
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
I am not sure that it has anything to do with large files.
I can reproduce it also with relatively small files. Leave Textmate open, maybe let it rest for some time, in a different screen, then DO NOT SELECT IT by clicking. Just change screen so that you have now TM in front of you and scroll the windows with the track pad (do not click on the windows), then you should see that parts of the windows are not refreshed at all, sometimes it is just the pane with the line numbers, sometimes it is the text as well.
Maybe this can help other people reproduce the bug, including the developers and contributors. I posted a message on textmate-dev and I got it back through the digest, but I do not see it in the web interface.
Attached: two examples:
http://textmate.1073791.n5.nabble.com/file/t2991/refresh-1.png  http://textmate.1073791.n5.nabble.com/file/t2991/refresh-2.png 
-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html
On 11 Oct 2019, at 17:35, mocenigo wrote:
I am not sure that it has anything to do with large files.
From the reports, it sounds more like a macOS 10.15 issue.
Is anyone *not* on macOS 10.15 seeing this?
The gutter and main text are actually two different scroll views with different code, the former being much simpler, so seeing gutter is also affected by this issue, it very much sounds like a bug that only Apple can fix.
On 11 Oct 2019, at 9:02, Jacob Carlborg wrote:
TextMate has always had problems with large files since the move to TextMate 2. I think the text rendering is implemented differently compared to TextMate 1.5.
TextMate 2 got a completely new layout engine that supported proportional width fonts, indented soft wrap, mixed fonts with different line heights, folding arbitrary subsets, enabling/disabling soft wrap for subsets, etc.
As obtaining text metrics is a slow operation, I decided to make it lazy, which is what has resulted in the unsatisfying behavior with soft wrap:
When scrolling through a file, lines will wrap the first time they are rendered, causing the total height of the document to change, and this can cause text to “jump around”.
This is worst if opening a file with many long soft wrapped lines, and then moving to the bottom, because the bottom of the file will then change after having moved there, and scrolling up is also very confusing when hitting a line that hasn’t been wrapped yet.
I’ve decided that rather than try to fix this for TextMate 2.0 it is better to write a new layout engine because the soft wrap issue is not the only thing I want to address.
I don’t want to say anything that can be interpreted as promises or pre-announcements, but the new layout engine / text view is what I am currently working on, and in addition to fixing the lazy layout issue, performance for large files (as in hundreds of megabytes) is also a high priority.
This happened in every beta version of TM2 in Catalina/Mojave/High Sierra/High Sierra/Yosemite with even few hundred of lines.
Not always but it did happen
1. while scrolling, some text at bottom of TM window may overlap others, continue scrolling up/down will clear the mess.
2. when using cmd+s search, after located the line, Esc to cancel bottom search bar, the mess might appear
3. when using cmd+s search, deleted some lines from visible area, continue scrolling down or cmd+s will get this mess.
-- Sent from my mobile. Ignore the typos unless they're funny.
On Mon, Oct 14, 2019 at 4:21 PM Allan Odgaard mailinglist@textmate.org wrote:
On 11 Oct 2019, at 17:35, mocenigo wrote:
I am not sure that it has anything to do with large files.
From the reports, it sounds more like a macOS 10.15 issue.
Is anyone *not* on macOS 10.15 seeing this?
The gutter and main text are actually two different scroll views with different code, the former being much simpler, so seeing gutter is also affected by this issue, it very much sounds like a bug that only Apple can fix.
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
Ok. It’s the lazy layout, I presume, that’s killing my work. So its degree of laziness got turned up between rc10 and 2.0. Could you turn it back? m.
-- matt neuburg, phd = http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 13! http://shop.oreilly.com/product/0636920310075.do iOS 13 Fundamentals! http://shop.oreilly.com/product/0636920310068.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
On Oct 14, 2019, at 1:45 AM, Allan Odgaard mailinglist@textmate.org wrote:
On 11 Oct 2019, at 9:02, Jacob Carlborg wrote:
TextMate has always had problems with large files since the move to TextMate 2. I think the text rendering is implemented differently compared to TextMate 1.5.
TextMate 2 got a completely new layout engine that supported proportional width fonts, indented soft wrap, mixed fonts with different line heights, folding arbitrary subsets, enabling/disabling soft wrap for subsets, etc.
As obtaining text metrics is a slow operation, I decided to make it lazy, which is what has resulted in the unsatisfying behavior with soft wrap:
When scrolling through a file, lines will wrap the first time they are rendered, causing the total height of the document to change, and this can cause text to “jump around”.
This is worst if opening a file with many long soft wrapped lines, and then moving to the bottom, because the bottom of the file will then change after having moved there, and scrolling up is also very confusing when hitting a line that hasn’t been wrapped yet.
I’ve decided that rather than try to fix this for TextMate 2.0 it is better to write a new layout engine because the soft wrap issue is not the only thing I want to address.
I don’t want to say anything that can be interpreted as promises or pre-announcements, but the new layout engine / text view is what I am currently working on, and in addition to fixing the lazy layout issue, performance for large files (as in hundreds of megabytes) is also a high priority.
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
I second this. Maybe it would be a nice idea to turn down lazy layout until the new layout engine is ready? Also, if this is in the lazy layout, why doe it affect the gutter?
-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html
Has this happened for mysterious reasons only to me or with the 10.15.1 update this phenomenon no longer occurs? Then it was indeed an Apple bug and there is no need for a code workaround (I think the programmers of Acorn mentioned that they had to add a workaround to their app because they had refresh problems under Catalina)
-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html
No, it happened again.... It seems to kick in only after some time?
-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html
Allan Odgaard-4 wrote
On 11 Oct 2019, at 17:35, mocenigo wrote:
I am not sure that it has anything to do with large files.
From the reports, it sounds more like a macOS 10.15 issue.
Is anyone *not* on macOS 10.15 seeing this?
The gutter and main text are actually two different scroll views with different code, the former being much simpler, so seeing gutter is also affected by this issue, it very much sounds like a bug that only Apple can fix.
I HAVE GOOD NEWS (perhaps). I observed a similar bug in Outlook for mac. If this is caused by the same bug in Catalina, Apple will fix it, and then it will be useful for us as well. I know the argument is thin, but there is always hope ;-)
-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html
On 8 Dec 2019, at 20:54, mocenigo wrote:
I HAVE GOOD NEWS (perhaps). I observed a similar bug in Outlook for mac. If this is caused by the same bug in Catalina, Apple will fix it, and then it will be useful for us as well. I know the argument is thin, but there is always hope ;-)
A user on the cocoa-dev list is also experiencing issues with lack of redraw after scroll on macOS 10.15, they shared this screen capture from a user: http://eyalredler.com/stuff/catalina_glitch.png
Here the bottom part is missing, so it does very much appear to be a macOS 10.15 issue, also because in TextMate, line numbers and main text view are different views, yet both are “clipped” (missing updates) the same way, and the screen capture shared earlier, shows that what got redrawn is exactly 640 pixels wide, which is not an unreasonable tile/texture size when doing window compositing.
However, there is one “non-standard” thing that TextMate does: It opts out of responsive scrolling (this is necessary to properly synchronise line numbers with the document content).
Therefore I would suggest people affected to try to enable responsive scrolling, just to rule this out, run the following in a terminal:
defaults write com.macromates.TextMate enableResponsiveScroll -bool YES
You will have to relaunch TextMate afterwards.
The only side-effect of this is that sometimes when scrolling a document, the line numbers will scroll with a sort of elastic delay.
I haven’t seen the issue since doing this: might be the solution. Also, I’ve not noticed any side effects, visual or otherwise. If anything just seems snappier?
Happy new year all, T
Sent from my iPhone
On 27 Dec 2019, at 19:13, Allan Odgaard mailinglist@textmate.org wrote:
On 8 Dec 2019, at 20:54, mocenigo wrote:
I HAVE GOOD NEWS (perhaps). I observed a similar bug in Outlook for mac. If this is caused by the same bug in Catalina, Apple will fix it, and then it will be useful for us as well. I know the argument is thin, but there is always hope ;-)
A user on the cocoa-dev list is also experiencing issues with lack of redraw after scroll on macOS 10.15, they shared this screen capture from a user: http://eyalredler.com/stuff/catalina_glitch.png
Here the bottom part is missing, so it does very much appear to be a macOS 10.15 issue, also because in TextMate, line numbers and main text view are different views, yet both are “clipped” (missing updates) the same way, and the screen capture shared earlier, shows that what got redrawn is exactly 640 pixels wide, which is not an unreasonable tile/texture size when doing window compositing.
However, there is one “non-standard” thing that TextMate does: It opts out of responsive scrolling (this is necessary to properly synchronise line numbers with the document content).
Therefore I would suggest people affected to try to enable responsive scrolling, just to rule this out, run the following in a terminal:
defaults write com.macromates.TextMate enableResponsiveScroll -bool YES You will have to relaunch TextMate afterwards.
The only side-effect of this is that sometimes when scrolling a document, the line numbers will scroll with a sort of elastic delay.
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
The issue is still there. Also with the "defaults write com.macromates.TextMate enableResponsiveScroll -bool YES" command and under 10.15.2 :-(
-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html
I too have this issue with TM; but it seems it may be really something macOS 10.15 related ... i just had the same issue with a larger diff in Sourcetree.
Am Fr., 3. Jan. 2020 um 22:36 Uhr schrieb mocenigo <roberto.avanzi@gmail.com
:
The issue is still there. Also with the "defaults write com.macromates.TextMate enableResponsiveScroll -bool YES" command and under 10.15.2 :-(
-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
Is it me or has this bug disappeared under 10.15.5? So far not able to reproduce. Fingers crossed.
-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html
Same here. The issue has appeared since with the 10.15.5 update.
-Ron
On Sun, May 31, 2020 at 8:43 AM mocenigo roberto.avanzi@gmail.com wrote:
Is it me or has this bug disappeared under 10.15.5? So far not able to reproduce. Fingers crossed.
-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
Oops. s/has/hasn't.
On Wed, Jun 3, 2020 at 1:17 PM Ronald Wampler rdwampler@gmail.com wrote:
Same here. The issue has appeared since with the 10.15.5 update.
-Ron
On Sun, May 31, 2020 at 8:43 AM mocenigo roberto.avanzi@gmail.com wrote:
Is it me or has this bug disappeared under 10.15.5? So far not able to reproduce. Fingers crossed.
-- Sent from: http://textmate.1073791.n5.nabble.com/textmate-users-f3.html
TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate
-
Allan Odgaard -
Ed Wong -
Gregg Kellogg -
Harald Lapp -
Jacob Carlborg -
Kelvin Wu -
Matt Neuburg -
mocenigo -
Ronald Wampler -
Timothy Bates