Horizontal scrollbar only considers visible document lines

Hi Tobias,

Sorry but no, I believe we do that as an optimization since otherwise you need to know the exact pixel length of every line in the document and account for things like collapsed nodes or other things that could affect lengths.  Further, as modifications were made you'd need to recalculate pixel lengths of every affected line, even offscreen ones.  So with large documents, that could affect performance.  And actually Visual Studio does the same thing for the same reasons.

Hm, you are right. I have never noticed that. But Visual Studio seems to have a more intelligent algorithm. For me the scrollbar almost never gets resized (VS 2010).
It seems that the maximum width of the document is cached. If the user scrolls and the currently visible width is greater than the cached maximum, the scrollbar is resized. If the user collapses a region, the scrollbar only is updated if the maximum is within the collapsed text range.
On the other hand, most edit operations are made within the visible area, so the scrollbar gets updated immediately. If the edit operation was outside of the visible area, the scrollbar gets updated when the changed are becomes visible. Documents that are not visible should never be updated until they become visible again.

I think it is a fair compromise between performance and usability. And if it affects performance, you can always make it an optional setting, which is disabled by default.

Hi Tobias,

Thanks for the suggestion and ideas.  We will write them down with the feature request.

Hi Tobias,

Thanks for this suggestion. We're now working on refactoring our view/scrolling internals and have implemented max width tracking improvements for SyntaxEditor vNext per this blog post:

http://blog.actiprosoftware.com/post/2017/11/13/SyntaxEditor-vNext-Is-Progressing