[fixedGutter] Gutter jumps as I scroll horizontally #730
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As I scroll horizontally, gutter is jumping due to asynchronous position update in onScrollMain. It sounds like horizontal scrolling needs treatment similar to the vertical one (i.e. making scrollbar/scrollbarInner fake horizontal dimension as well).
I do realize it might add come complexity, but I was wondering what your take on it was? Would you be willing to implement it? Would you be open to getting a pull request? Any complexities involved that you know of?
fixedGutteris, most likely, on its way out. As you noticed, it is flaky (jittery), and in the new gutter and line-height model that version 3 will use, there's no efficient way to implement it. If people care a lot about this feature, I could implement it in an inefficient way (requires walking N nodes and repositioning them on every horizontal scroll event, where N is the number of visible lines -- and would still be jittery). But personally, I'm not too fond of the feature.Where do I learn more about v3, its features and milestones? I am asking since I am assessing the potential use of CodeMirror as a part of the WebKit Web Inspector. We are using fixed gutter in the present editor and would not want to change the model.
Actually, to make sure I understand the problem properly. I thought that adding horizontal scroll to the scrollbar, hiding it from the scroller and adjusting gutter's style upon onscroll + delegating it to the scroller's scrollLeft would solve it. There probably are complexities I don't understand.
See https://groups.google.com/forum/?fromgroups#!topic/CodeMirror/mSFsEmhn1Cs%5B1-25%5D
If a fixed gutter is a requirement for Webkit integration, I'm willing to take that seriously. The main problem is that line numbers need to be vertically positioned relative to the line that they are part of, so they are children of that line in the new model. To have a moving gutter, they'd have to be horizontally positioned relative to that gutter. I know of no way to obtain that effect in HTML/CSS, so we'd have to resort to changing their position through a script that reacts to scroll events. This script will, on most browsers, only run after the actual scrolling took place, so you'll get the jitter you noticed -- the numbers first move, then snap into place again.
Oh, Ok, I see. I started from this way of living in the WebKit's editor, but then we needed to make gutter an independent div to the left from the main area + we sync the vertical offsets using JS. Syncing height turned to be less noticeable - rows don't change their height too often.
As for the WebKit integration requirements, fixed gutter is fairly important to us, primarily due to the breakpoint markers. We don't want breakpoints to get behind the screen - one would need to scroll to remove them + you always want to know what line you are at. We don't have line wrapping and even if we did, it would be turned off by default. So yes, it is important for our use cases. Tell us if we can help with it.
Thanks for the details. The main motivation behind positioning the line numbers inside the lines that they belong to, instead of in a separate gutter element, is performance -- repopulating the whole gutter every time something changed is quite expensive in the current codebase.
But I guess would be possible to still provide this model in version 3, and turn it on when
fixedGutteris active. I'm not making a decision on this right now, but I'll think about it some more.mentioned in issue #727
The v3 branch now contains a working implementation of a fixed scrollbar (that even handles varying-height lines). I won't fix this in the v2 series (too invasive to do in a backwards-compatible way).
Thanks Marijn! v3 is looking great.