12 Nov
2018
12 Nov
'18
5:04 p.m.
I’m running the latest RC 2.0-rc.15. I’ve only noticed this since I've installed this
version.
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.
I’m not sure how TM handles window draws but there seems to be a miscalculated line offset
between a buffered text image that gets shown when the window first shows and then an
actual redraw of lines afterwards. I’ve noticed in some cases a clipped portion of the
window being shown first and then the remaining page showing but the clipping is off so
the text appears to move downwards. Sorry I haven’t looked into the code to get a better
idea of what’s happening with window draws.
Ed Wong
13 Nov
13 Nov
5:28 p.m.
On 12 Nov 2018, at 12:04, Ed Wong wrote:
I’m running the latest RC 2.0-rc.15. I’ve only noticed
this since
I've installed this version.
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.
I switched back to macOS’s “Light” appearance this morning and
started seeing this, too.
It’s entirely possible I just hadn’t noticed before, but in case
anyone is unable to reproduce it, maybe it doesn’t happen in dark
mode.
--
Rob McBroom
http://www.skurfer.com/
14 Nov
14 Nov
4:19 a.m.
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.
3:09 p.m.
Thanks for looking into this Allan.
Ed
On Nov 13, 2018, at 11:19 PM, Allan Odgaard
<mailinglist(a)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.
_______________________________________________
textmate mailing list
textmate(a)lists.macromates.com
https://lists.macromates.com/listinfo/textmate
26 Apr
26 Apr
5:28 p.m.
On 13 Nov 2018, at 23:19, Allan Odgaard wrote:
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.
The fix for this doesn’t sound like something you’re going to knock
out in a few hours, but is there any progress or anything else we can do
in the short term? This is driving me nuts.
I’ve been working on some code for a client with pretty long lines.
Switching to a document scrolls more than a page, and it’s not obvious
which direction it went. So I don’t know exactly how far away the
current line is, and I don’t know which way to look.
I’ve found that ⌃L seems to work once the view has stabilized, but
that gets old fast. Now I’m experimenting with just turning soft-wrap
off. We’ll see how that goes. (The code for this particular project is
unreadable anyway. 😛)
--
Rob McBroom
27 Jun
27 Jun
4:57 a.m.
On 26 Apr 2019, at 19:28, Rob McBroom wrote:
On 13 Nov 2018, at 23:19, Allan Odgaard wrote:
I use ⌘J for “Jump to Selection” myself. Not that different from
your current workaround, but it only centers the insertion point without
moving it or changing selection.
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.
The fix for this doesn’t sound like something you’re going to
knock out in a few hours, but is there any progress or anything else
we can do in the short term? This is driving me nuts.
I’ve been working on some code for a client with pretty long lines.
Switching to a document scrolls more than a page, and it’s not
obvious which direction it went. So I don’t know exactly how far
away the current line is, and I don’t know which way to look.
654
days inactive
881
days old
5 comments
3 participants
participants (3)
-
Allan Odgaard -
Ed Wong -
Rob McBroom