Correct. The editing widget we use does not measure the length of lines to determine the width of the longest line since that would require laying out and measuring the entire file instead of only the visible area. So it tracks the longest line that it has displayed and sets the scroll bar for that, but it starts with an initial guesstimate of 2000 pixels, which might be about 300 chars depending on your font size.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/886#issuecomment-174978155

The widget can be told what to use, but "somebody" has to write the code to do it (and possibly the UI to set the preference).

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/886#issuecomment-174991322

Why is "somebody" in quotes? If anyone wants to implement this, it would be most welcome, IMO.

Well, it's easy enough to implement naively, and I gave it a shot for fun: https://github.com/b4n/geany-auto-scroll-width. It's a little more tricky to auto-hide the bottom scrollbar, but also doable.

But getting a version with zero performance impact would probably be a lot harder to do, and I guess would require altering Scintilla itself to store layout length in the line data itself, plus a global per-document value, and only re-compute the max width when the line changed width and had the largest width (if new width is larger, just update using this new value, instead find the new largest).

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/886#issuecomment-175190111

@codebrainz because its traditional (TM Enrico) :)

@b4n, don't use on large files, `get_longest_line_width()` causes the whole file to be laid out and measured every update UI. If its added to Geany what it will cost you is complaints from people who open large files with it on. We already have had complaints about lexers running on large files, let alone this. :)

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/886#issuecomment-175273065

I honestly don't see what real value it adds

It wastes 20 or whatever pixels for no good reason is one issue. I generally keep the window wide enough that my ~80 chars of code would fit, so not only showing a really long scrollbar wastes vertical screen space but it makes me think I screwed up and have a really long line. Also the scroll thumb doesn't actually reflect the width of the lines properly so it's even more misleading. I can always tell if an editor is using Scintilla by whether it has broken/buggy horizontal scrollbar :)

I guess would require altering Scintilla itself to store layout length in the line data itself

I tend to agree it should be added to Scintilla proper, turned off by default. Then editors could choose whether to have a broken scrollbar, or to enable to fix if a file is under a certain size or whatever.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/886#issuecomment-175293398

@techee I assume it uses [SCI_SETSCROLLWIDTHTRACKING](http://www.scintilla.org/ScintillaDoc.html#SCI_SETSCROLLWIDTHTRACKING), which only makes the situation worse since it never shrinks the scrollbar smaller, making it even more confusing when looking at the scrollbar as some kind of indication of how far horizontal scroll is. I never actually looked at SciTE code to see if it does something smarter.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/886#issuecomment-176828006

I just want to add my +1 to this. It's a bit annoying when you have a fixed column width set, so you'll never have any characters going beyond that limit. I'm coming from gedit, which does not have this issue.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/886#issuecomment-188461329

So it tracks the longest line that it has displayed and sets the scroll bar for that, but it starts with an initial guesstimate of 2000 pixels, which might be about 300 chars depending on your font size.

Doesnt that mean we can simply reduce the initial estimate and then it'll be better fit, and it will work for cases where the estimate is wrong?

Why not just set the estimate to, like, 120 chars then?

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/886#issuecomment-192866581

Why on the monitor resolution?

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/886#issuecomment-192868070

I see. So let's measure the width (pixels) of the M or W character and use that. For monospace fonts (common case) it doesn't matter, and for others it's a defensive default.

--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/886#issuecomment-192875656

@HybridDog you can turn on Line Wrapping which will disable horizontal scrolling.

How about showing the horizontal scroll bar only when there are lines which scroll right? And yes, it would be wonderful if the horizontal scroll bar would scroll as far right as the longest line in the file.

Notepad++, also based on Scintilla, does it well.