New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[fixedGutter] Gutter jumps as I scroll horizontally #730
Comments
|
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 |
This will make fixedGutter solid, and make it the only model (no more gutter that scrolls out of view). Issue #730
This will make fixedGutter work properly, and make it the only model (no more gutter that scrolls out of view). Also reorganizes the basic css file to be easier to modify for users. Issue #730
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. |
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?
The text was updated successfully, but these errors were encountered: