Skip to content
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

Horizontal scroll bar is far wider than longest line in the file #886

Open
ThosRTanner opened this issue Jan 26, 2016 · 26 comments
Open

Horizontal scroll bar is far wider than longest line in the file #886

ThosRTanner opened this issue Jan 26, 2016 · 26 comments

Comments

@ThosRTanner
Copy link

With geany 1.24.1. Pretty much any file, even if it has a maximum line length of 80 characters - the horizontal scroll bar is about 300 characters wide, so it's hard to tell if there's a very long line in the file without actually examining each line.

@elextr
Copy link
Member

elextr commented Jan 26, 2016

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.

@ThosRTanner
Copy link
Author

any way of reducing/configuring the guesstimate?

@elextr
Copy link
Member

elextr commented Jan 26, 2016

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).

@codebrainz
Copy link
Member

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

@b4n
Copy link
Member

b4n commented Jan 26, 2016

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).

@b4n
Copy link
Member

b4n commented Jan 26, 2016

Ah, and I honestly don't see what real value it adds. Visual clue to how long is the longest line? I hardly see a use case for this. But well, so long as it doesn't negatively impact me I don't care if it works :)

@elextr
Copy link
Member

elextr commented Jan 26, 2016

@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. :)

@b4n
Copy link
Member

b4n commented Jan 26, 2016

@elextr I know, laying out the whole file is the very problem of this :) and probably the very reason it's not built in Scintilla already.

@codebrainz
Copy link
Member

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.

@techee
Copy link
Member

techee commented Jan 29, 2016

At least in SciTE there's

output.horizontal.scroll.width.tracking

property to do this (http://www.scintilla.org/SciTEDoc.html). Is this done purely in SciTE code or is there some native support in Scintilla for this feature that we could use? (Haven't checked myself.)

@codebrainz
Copy link
Member

@techee I assume it uses 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.

@elextr
Copy link
Member

elextr commented Jan 29, 2016

@techee @codebrainz and we set SCROLLWIDTHTRACKING on, hard coded.

@mscdex
Copy link

mscdex commented Feb 24, 2016

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.

@b4n
Copy link
Member

b4n commented Feb 24, 2016

@kugel-
Copy link
Member

kugel- commented Mar 6, 2016

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?

@elextr
Copy link
Member

elextr commented Mar 6, 2016

@kugel- sadly its in pixels so it depends on your font size and monitor resolution.

@kugel-
Copy link
Member

kugel- commented Mar 6, 2016

Why on the monitor resolution?

@elextr
Copy link
Member

elextr commented Mar 6, 2016

Font size is in points, which is 1/72th of an inch, so varying DPI of the monitor makes the pixels per character different even for the same font size.

@kugel-
Copy link
Member

kugel- commented Mar 6, 2016

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.

@HybridDog
Copy link

l'm using a touchpad and changed the synaptics configuration that l can scroll horizontally.
In geany this is really annoying:

  • You can scroll right without limit.
  • When scrolling up and down you need to take care to not scroll right accidentally.

Can l somehow disable horizontal scrolling?

@codebrainz
Copy link
Member

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

@HybridDog
Copy link

Thanks, it works after restarting.

@LadyAleena
Copy link

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.

@elextr
Copy link
Member

elextr commented May 12, 2017

@LadyAleena unfortunately Scintilla does not track the length of lines not on screen so as to avoid having to perform layout on the whole file, therefore it can't know when horizontal scrolling is needed.

@LadyAleena
Copy link

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

@codebrainz
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants