mcview Down/PageDown/End weirdnesses

[egmont]

mcview handles Down / Page Down / End keypresses in a really weird and buggy way when you're near the end of the file.

Let me open this ticket to discuss the desired behavior (which I'll implement in #3250).

The current behavior is:

• End takes you to the position when the last line of the file is at the bottom of the viewport.

• Down arrow scrolls by one line, until the last line of the file reaches the top of the viewport (and the rest of the viewer area is blank). So, it scrolls beyond the position you reach with End.

• Page Down scrolls by one (or half) page, except when the last line of the file appears. Then it stops at this position (this is where End takes you), but subsequent presses of Page Down scroll by 1 more line (wtf?), making upwards and downwards scrolling a different experience (why?).

• Page Down is not equivalent to pressing Down a screen heightful of times, even though Page Up is equivalent to pressing Up that many times. End is not equivalent to pressing Down or Page Down until the file no longer scrolls, even though Home is equivalent to pressing Up or Page Up enough times.

It's one thing that the implementation is buggy (e.g. in mcview_move_down() the condition
if (view->dpy_end - view->dpy_start > last_byte - view->dpy_end) {...}
means "if the currently displayed length in bytes is larger than the remaining length of the file in bytes", this clearly on so many levels doesn't correspond to the height of the text, and so it's very easy to construct a file where Page Down scrolls by a totally wrong amount).

But what bugs me more is that the behavior does not make any sense to me. Especially Page Down that slows down to only scroll by one line. This is a pattern I have never ever seen anywhere else. It's unorthodox, unexpected, and hence misleading, and I can't see any argument that could defend this behavior. None of the apps I've ever seen does this, mcview in hex mode doesn't do this, mcedit doesn't do this, mc's help viewer doesn't do this, mc's file listing panels don't do this, noone else does this.

Looking at how other apps (vim, emacs, less, mcedit...) behave, they're pretty much all different. However, I don't think that apps carrying the legacy of decades should define what to do.

If you look at any non-terminal apps (graphical editors, web browsers, mobile applications etc. displaying any scrollable content), the modern trend suddenly becomes clear, and I think it's the only reasonable behavior:

• If the file is shorter than the viewport, it's always aligned to the top and no scrolling is possible.

• If the file is taller than the viewport, it can be scrolled to the point where its last line appears at the bottom, and never beyond this position. That is, never waste screen real estate. End takes you to this position. Page Down scrolls by a page (or by half page) but at most to this position.

• Page Down is becomes equivalent to pressing Down a screen heightful of times. End becomes equivalent to pressing Down or Page Down until the file no longer scrolls.

• When searching for text, the match can not always be scrolled to the top. It's okay if it appears somewhere else on the screen, if the found text is near the end of the file.

• When jumping to a given line (this is analogous to the behavior of browsers when there's a '#' anchor in the URL), again the desired line might not be the topmost one. If it's somewhere below then you don't necessarily know where it is (but it's the same problem with browsers), I think it's okay to live with this compromise. If absolutely necessary, some visual emphasis could be applied (e.g. highlight the whole line with the search result's color, removed with a timeout or at a keypress).

At the current state of ticket 3250, it's fairly easy to implement any scrolling behavior (without bugs). The old code however definitely needs to be rewritten, and I don't see any point reimplementing that behavior, I'd like to go for the one outlined here.

[egmont]

If anyone wants to give it a try, it's implemented at ​https://github.com/egmontkob/mc-3250 (c8c8486)

[egmont]

From #3250 (comments 12-18, 27-29):

My suggested behavior breaks the probably least used and hardest to discover feature of mcview: Ctrl+E taking you to the end of the topmost line in unwrap mode. Since the last (height-1) lines of the file can no longer appear at the top of the viewport, this feature becomes unavailable for those lines.

Copying from comment 27 in that ticket:

«[M]y current recommendation [...]:

Make mcview default to what's [described in this ticket]. This way scrolling would be limited to the point where the last line of the file reaches the bottom of the screen, and hence jump-to-eol would be available for all but the last height-1 lines.

And have a hidden config option for experts that let you enable scroll beyond eof, until the last line of the file reaches the top of the screen. (The exact details of how End and Page Down behave could exactly match current mc, or could be fine tuned if required.) If that option is enabled, the search result can always show up on the top line, the Goto Line feature always brings the desired line to the top, and Jump To Eol becomes available for all lines of the file.

I'm happy to implement this if this sounds like a good enough solution for everyone. (Note that mcview_eof=~ is already such a hidden option, and I guess there's a noticeable correlation between people who want to scroll beyond eof and people who want to see ~ chars.)»

[ossi]

capping downwards motion makes pageup usually not return you where the previous near-bottom pagedown started from. so symmetry as the ultimate argument simply doesn't work.
but i'll grant you that downarrow going further than "real" pagedown is plain weird.
being able to scroll below the bottom has the already mentioned advantage that one can use the top line as a cursor, e.g. for search hits and the ctrl-e function.
when you accept that scrolling past the end is as such useful and take the other considerations into account, there is only one possible conclusion: pagedown should scroll an entire page even if that means that EOF lands in the middle of the page. only the next press would be capped by putting the last line at the top.
and yes, 'end' would still put the last line at the bottom (unless you are past that position already, in which case it should do nothing, so it doesn't jump back). i don't see harm in that, as it's a rather different navigation pattern.

now, there are two arguments against scrolling past the end:

• it's "a bit different" from what everybody else does. that's not a problem as such as long as it's obvious enough and thus doesn't cause confusion.
• the use of the top line as an "invisible" cursor isn't perfect - one misses context upwards from a search hit. and moving the hit line down adds a whole slew of new weirdness if one tries to stick with the pattern "a particular fixed line is the cursor".

i'll continue the discussion about the cursor problem in #3250.

[egmont]

Replying to ossi:

capping downwards motion makes pageup usually not return you where the previous near-bottom pagedown started from. so symmetry as the ultimate argument simply doesn't work.

Simiarly, from a near-top position a pageup followed by a pagedown doesn't take you back there either. So it *is* symmetrical.

and yes, 'end' would still put the last line at the bottom

I see no logic whatsoever in this (albeit I'm happy to implement this as one of the two possible option, reachable by a hidden config option).

now, there are two arguments against scrolling past the end:

• it's "a bit different" from what everybody else does. that's not a problem as such as long as it's obvious enough and thus doesn't cause confusion.

It is very different. The main purpose of the viewer is to *view* the contents described in the file. If a pagedown or tapping the down arrow scrolls too much then it hides the content from me for showing whitespace instead – it is against the main purpose. I don't want to see unnecessary whitespace ever, I want to see as much from the file contents as possible.

• the use of the top line as an "invisible" cursor isn't perfect - one misses context upwards from a search hit. and moving the hit line down adds a whole slew of new weirdness if one tries to stick with the pattern "a particular fixed line is the cursor".

Web browsers, pdf viewers etc. all managed to solve these problems without scrolling beyond the end. Yes they do pay a minor price for that, e.g. # anchor not bringing the desired position to the top, but this price is in my firm opinion much better than showing a pageful whitespace at the bottom.

I think we should agree by now that there is no single perfect solution, and there's not much point still trying to find that. Certain solutions have an upside here and a downside there, other solutions make a compromise somewhere else. The main question is where to make that compromise.

In my firm opinion, the behavior should mimic the behavior of all modern scrolling widgets (e.g. webpages in browsers, pdf viewers, settings pages of mobile apps, etc.) and make the most standard feature (viewing and scrolling) as good as possible; and make a sacrifice in the lesser used features (jumping to a particular position – maybe that position will not be at the top, deal with it; jumping to EOL, the probably single least used feature – won't be available for the last few lines, but there are workarounds for that; again deal with it).

That being said, I'm still happy to implement two behaviors: one that makes sense to me, and one that you/angel_il/whoever come up with.

[ossi]

Replying to egmont:

Simiarly, from a near-top position a pageup followed by a pagedown doesn't take you back there either. So it *is* symmetrical.

yes, symmetry in one place, non-symmetry in another. point proven.

and yes, 'end' would still put the last line at the bottom

I see no logic whatsoever in this

it makes sense, because "i'm scrolling through a file" is a very different use case than "i'm jumping to the end of the file".

(reachable by a hidden config option).

total nonsense, and you know that.

It is very different.

The main purpose of the viewer is to *view* the contents described in the file.

that's a non-sequitur to the "being different" argument.

If a pagedown or tapping the down arrow scrolls too much then it hides the content from me for showing whitespace instead – it is against the main purpose. I don't want to see unnecessary whitespace ever, I want to see as much from the file contents as possible.

when you move down after you have been at a particular point, you do that because you've processed the information that was in view and want to move on. there is absolutely no reason why the bottom of the file should be treated differently from every other page.

Web browsers, pdf viewers etc. all managed to solve these problems without scrolling beyond the end.

the main difference is that they concentrate on flowed text, and can assume the presence of an efficiently usable pointing device when push comes to shove.

also, ever used xpdf? just to prove "all" being untrue. :P

you can have "your" scrolling semantics, but only if you address the problems with the search function(s) to a sufficient degree. it's a package deal.

[egmont]

Replying to ossi:

yes, symmetry in one place, non-symmetry in another. point proven.

I really don't understand you at this point.

it makes sense, because "i'm scrolling through a file" is a very different use case than "i'm jumping to the end of the file".

Wow, so the "end" of the document is defined by the means you're navigating?

(reachable by a hidden config option).

total nonsense, and you know that.

Yeah I know, exactly the kind of nonsense as scrolling beyond EOF.

when you move down after you have been at a particular point, you do that because you've processed the information that was in view and want to move on. there is absolutely no reason why the bottom of the file should be treated differently from every other page.

What kind of "page" are you talking about? Text files don't have the concept of "pages".

If you can scroll beyond EOF, why can't you do that at BOF? Why can't you press the up arrow a few more times until the first line of the file reaches the bottom of the screen, with tons of whitespace above?

If you're so strong on your opinion, could you please explain to me why web browsers don't behave this way, why they don't add an almost screenful of whitespace at the end of every document if you navigate by down or pagedown? Would you care to file them feature requests, and see their reactions?

Web browsers, pdf viewers etc. all managed to solve these problems without scrolling beyond the end.

the main difference is that they concentrate on flowed text, and can assume the presence of an efficiently usable pointing device when push comes to shove.

Text files are also flowed text, there's no difference in this regard. You can use keypresses to scroll browsers. As far as I know (I might be wrong), mouse clicks don't influence where searching starts/continues from. And you even have a pointing device in mc if you want. So there's absolutely no core difference that would justify a substantially different behavior.

also, ever used xpdf? just to prove "all" being untrue. :P

I have just tried, and can't see what's your point. As opposed to mcview, xpdf displays documents that are by definition divided into pages. It can scroll to the end of the last page, and not any further.

In text files displayed by mc, the notion of page does not exist. You can press down, pagedown, resize mc in any order you wish, and there's no way to define or enforce what a "page" of the file means, exactly as with html pages in your browser.

you can have "your" scrolling semantics, but only if you address the problems with the search function(s) to a sufficient degree. it's a package deal.

What are the problems with search in my current version, again? I can't remember you mentioning any bug, sorry if I missed it.

[ossi]

Replying to egmont:

Replying to ossi:

yes, symmetry in one place, non-symmetry in another. point proven.

I really don't understand you at this point.

the point is that you *pick* your symmetry axes/points. you need to make a choice which ones these are. also, you need to weight the benefits of symmetry against other practical concerns. the whole thing is inherently asymmetrical (top-left orientation, for starters), which rather obviously makes "because symmetry" as such a non-argument.

Wow, so the "end" of the document is defined by the means you're navigating?

we are discussing the presentation of the end of the document, not the end of the document.

What kind of "page" are you talking about? Text files don't have the concept of "pages".

the pagedown button introduces the concept (in an obviously dynamic way).

If you can scroll beyond EOF, why can't you do that at BOF? Why can't you press the up arrow a few more times until the first line of the file reaches the bottom of the screen, with tons of whitespace above?

i actually have considered that as a solution to providing context in front of a hit - remember "whole slew of new weirdness"? yes, that.
apart from being *really* unusual, it has the downside of initially wasting screen estate in a situation where it actually matters (the assumption being that you want to start reading at the top. otherwise you'd hit 'end' right away (and expect to initially see as much of the end of file as possible, which also explains why scrolling down and jumping down are two inherently different use cases)).

If you're so strong on your opinion, could you please explain to me why web browsers don't behave this way, why they don't add an almost screenful of whitespace at the end of every document if you navigate by down or pagedown?

because they don't need to. you also don't need to if you solve the other problems adequately.

Text files are also flowed text, there's no difference in this regard.

flowed == automatically wrapped.
part of the discussion is concerned about long lined/horizontal scrolling, which is why it's relevant. if you take out that issue, then yes, they do pretty much the same. then only the difference in primary interaction device remains.

also, ever used xpdf? just to prove "all" being untrue. :P

I have just tried, and can't see what's your point. As opposed to mcview, xpdf displays documents that are by definition divided into pages. It can scroll to the end of the last page, and not any further.

the point was that navigation between pages works *only* with pageup/down. that's not an argument for anything, except that your generalized statement was simply wrong.

anyway, both xpdf and okular display the *whole* last page. if you accept that it logically doesn't matter whether the pages are statically or dynamically determined, it totally makes sense that you can page beyond eof, because that's simply the empty space of the last page. but of course it makes no sense to artificially define page boundaries, so you can also freely move in that space.

[egmont]

Replying to ossi:

the point is that you *pick* your symmetry axes/points. you need to make a choice which ones these are. also, you need to weight the benefits of symmetry against other practical concerns. the whole thing is inherently asymmetrical (top-left orientation, for starters), which rather obviously makes "because symmetry" as such a non-argument.

I want the behavior to be symmetrical wrt. up vs. down movements, start vs. end of document etc. By no means am I aiming for left-right symmetry. And of course we're talking about the case when the text file is taller than the viewport, otherwise the symmetry is broken by aligning at the top.

I still don't see any reason why the bottom of the document vs. the bottom of the viewport should be any different story than the top of the document vs. the top of the viewport.

the pagedown button introduces the concept (in an obviously dynamic way).

I believe that's where we mostly disagree. No, the pagedown button doesn't introduce the concept of "pages" in the text file. It just scrolls by a larger amount. (Do you know mc can be configured so that pagedown scrolls by half a page? Do you know the exact definition of "half" (whether rounding upwards or downwards)? Do you know that certain other console apps default to or can be configured to have an overlap of a line or two when pagedown is pressed? What's the definition of "page" in these cases? How does the definition of "page" change dynamically when you resize mc, or when you use the single up/down arrows?)

No, text files don't have pages, exactly as websites (html's) don't have. (PDFs are a different story, they do.) The viewer doesn't introduce this concept either, it just couldn't do. It just scrolls by a larger amount.

If you really insist that the viewer introduces the concept of pages (which I haven't seen in the previous implementation, nor added in my own one), could you please care to give an exact definition? How do these exactly change on up/down/home/end/pageup/pagedown/resize and what should pageup/pagedown do exactly?

If you can scroll beyond EOF, why can't you do that at BOF?

i actually have considered that as a solution to providing context in front of a hit

Yay. The last time I didn't get your Monty Python reference, now you didn't get the irony. Sure, let's go for even more unorthodox solutions that noone has even done because that's so cool and sure that's the right thing to do!

If you're so strong on your opinion, could you please explain to me why web browsers don't behave this way, why they don't add an almost screenful of whitespace at the end of every document if you navigate by down or pagedown?

because they don't need to. you also don't need to if you solve the other problems adequately.

Rarely though, but you get to see html pages where text scrolls out far to the right, and they offer no way of jumping to the end of the line. It's an extremely rare case in mcview too (but for some reason it became your pet peeve just recently), yet it offers an almost perfect solution for that (that just doesn't work for the last few lines now, still much better than browsers). I still feel you're trying to tailor a most basic feature (scroll boundary) to fully satisfy the needs of the least significant feature (jump to eol). Also, as I've pointed out, I'm not aware of any bugs wrt search right now.

but of course it makes no sense to artificially define page boundaries, so you can also freely move in that space.

So it makes no sense, yet you still insist??? I don't get you. Moreover, you should realize that this would lead to a different behavior. If you defined pages, the amount of whitespace you get at the end of the document should be somewhere from 0 to (height-1), depending on the file height modulo viewport height. E.g. with 80x24 terminal, where mcview is 22 lines high, a text file of 40 lines should only have 4 blank lines at the bottom. Instead, you always get almost a pageful (21 lines in this case) of blank. So, where are the page boundaries, again??? Please realize that this concept does not exist for text files and any attempt to define it would just overcomplicate things and is doomed to fail badly. Please just forget it for good! Text file is a continuous thing, just like html, with no page boundaries. Pageup and pagedown buttons scroll by a certain amount of lines. That's the single right way of thinking about them in mcview. (Viewers of a document format which does have pages is a totally different story.)

[ossi]

Replying to egmont:

And of course we're talking about the case when the text file is taller than the viewport, otherwise the symmetry is broken by aligning at the top.

yes, exactly. the case where there is space at the bottom already exists. why would "too short" files be different from "long enough" files? that's also an inconsistency (even if not an asymmetry).

Yay. The last time I didn't get your Monty Python reference, now you didn't get the irony.

the fact that you consider it a joke doesn't change the fact that i seriously considered the option and its implications.

Sure, let's go for even more unorthodox solutions that noone has even done because that's so cool and sure that's the right thing to do!

well, you clearly are very big on that orthodoxy thing. i for one would happily choose an unorthodox solution if it actually was superior. and yes, that would be cool.

Rarely though, but you get to see html pages where text scrolls out far to the right,

correct, because that usually indicates just bad page design.

and they offer no way of jumping to the end of the line.

they do ... the mouse.

It's an extremely rare case in mcview too,

viewing log files is actually a rather common use case for mcview. and these do have rather long lines sometimes, for extra nastiness interspersed with short lines.

but of course it makes no sense to artificially define page boundaries, so you can also freely move in that space.

So it makes no sense, yet you still insist???

it makes no sense to define boundaries, as in, make them uncrossable (except with pageup/down). it makes sense to consider the document as abstractly paged, because that's one way of actually viewing it. and as it happens, this in no way contradicts the notion that pagedown is just a series of down-presses.

If you defined pages, the amount of whitespace you get at the end of the document should be somewhere from 0 to (height-1), depending on the file height modulo viewport height.

funny that i said exactly that in comment:3, 4th paragraph.

and there is absolutely no complication introduced by that. all the code paths necessary to support that must exist anyway.

so the question remains whether it makes sense. it does in the context of the ctrl-e function, so until you come up with a better solution for that, it seems prudent to keep it supported.
that is *independent* from what you do with the pagedown key.

[egmont]

Replying to ossi:

well, you clearly are very big on that orthodoxy thing. i for one would happily choose an unorthodox solution if it actually was superior. and yes, that would be cool.

There's a viewport and there's a content you want to display. There's not much room for improvement and coming up with superior ways of solving it compared the most trivial one done e.g. by browsers. I doubt anyone could come with something new here that's "cool" rather than pathetic.

Rarely though, but you get to see html pages where text scrolls out far to the right,

correct, because that usually indicates just bad page design.

I bet you've also seen log files, stack dumps etc. in browsers, haven't you?

and they offer no way of jumping to the end of the line.

they do ... the mouse.

Jumping to the end of a particular line with the mouse in browsers is hardly any easier than using Ctrl+Right in mcview.

so the question remains whether it makes sense. it does in the context of the ctrl-e function, so until you come up with a better solution for that, it seems prudent to keep it supported.

So, do I summarize it correctly below?

• According to you, every single feature, even the tiniest one, has to remain at least as good as it was previously, it's unacceptable if the least used feature suffers from a small degradation for the sake of a bigger win, and it's unacceptable to drop the probably least significant feature.

• According to me, it is acceptable to make some compromises for an overall significantly better product.

• You'll be happy with my recommendation of scroll boundaries if something equivalent to current Ctrl+E would exist there. What would you find a good solution? Search for regexp "$"? Make Ctrl+E iterate over the lines (maybe with some visual highlight)? Make mouse rightclick jump to the end of that line? Have a context menu for mouse rightclick including this option? Any other idea?

I would still *hate* to tailor the scroll boundaries to please such an insignificant and hardly known feature of mcview.

[ossi]

Replying to egmont:

I bet you've also seen log files, stack dumps etc. in browsers, haven't you?

i actually *said* i did.
but that's not a case web browsers are optimized for. it's annoying to use them this way.
but at least it works reasonably well.

Jumping to the end of a particular line with the mouse in browsers is hardly any easier than using Ctrl+Right in mcview.

depends on how often you need to click ctrl-right. and then ctrl-left. and then again ... you get the idea. i hope.

• According to you, every single feature, even the tiniest one, has to remain at least as good as it was previously, it's unacceptable if the least used feature suffers from a small degradation for the sake of a bigger win, and it's unacceptable to drop the probably least significant feature.

the thing is, you still failed to provide an actual reason why scroll-past-eof is bad. even if i accept that ctrl-e is just 0.1, it still competes against 0.0 - and thus wins.

• You'll be happy with my recommendation of scroll boundaries if something equivalent to current Ctrl+E would exist there. What would you find a good solution? Search for regexp "$"? Make Ctrl+E iterate over the lines (maybe with some visual highlight)?

correct.

Make mouse rightclick jump to the end of that line?

that's an interesting idea for mouse-based navigation. but:

• it's hard to discover, so the total benefit would be suboptimal. not that ctrl-e is currently much different in this regard, but at least it *could* be made visible in a somewhat, err, orthodox way.
• a horizontal scroll bar would be a much more conventional approach, and mc happens to have the infrastructure. or at least there are patches for it floating around.
• of course, it should not be the only way to access the feature, as mc is primarily keyboard-focused

Have a context menu for mouse rightclick including this option?

completely unviable for the purpose of quick & convenient navigation.

Any other idea?

nope

[egmont]

Replying to ossi:

the thing is, you still failed to provide an actual reason why scroll-past-eof is bad. even if i accept that ctrl-e is just 0.1, it still competes against 0.0 - and thus wins.

You don't seriously think ctrl-e is 0.1, do you? It's more like 0.001 or even less. Maybe 0.1 for you, and 0 for 99+% of the users.

Did I fail to provide a reason why scroll-past-eof is bad, really? I can only repeat myself, I don't have anything new to tell. Because that's how every sane document viewer works, that's the obvious UI trend of this millennium, that's the conventional behavior, that's what most users are used to. Because I'd like to view the file contents, not the file contents in the middle of a larger white canvas. Because the other approach is vertically asymmetrical for no reason. Because the other approach introduces an inconsistent stopping point for end vs. down and pagedown. If you think these all sum up to 0.0 then there's nothing to talk about.

• You'll be happy with my recommendation of scroll boundaries if something equivalent to current Ctrl+E would exist there. What would you find a good solution? Search for regexp "$"? Make Ctrl+E iterate over the lines (maybe with some visual highlight)?

correct.

Okay I think this will the approach then.

Make mouse rightclick jump to the end of that line?

that's an interesting idea for mouse-based navigation. but:

• it's hard to discover, so the total benefit would be suboptimal. not that ctrl-e is currently much different in this regard

Well, a right click is probably easier to discover than ctrl-e.

Since current right-click is the same as left-click and hence is pretty useless, I'm supportive of this feature. Maybe it could toggle between ctrl-e and ctrl-a (execute ctrl-a if the current column is where ctrl-e would take you, in the spirit of #1480), in that case you could click on the first word of a very long line to jump to the end. Or, alternatively, it could be ctrl-a/ctrl-e depending on whether you click in the left/right half of the screen. Any preference? (My weak vote goes for the second.)

• a horizontal scroll bar would be a much more conventional approach, and mc happens to have the infrastructure. or at least there are patches for it floating around.

How would a horizontal scrollbar help you get quickly to the end of a particular line? I don't get it. Ctrl-e is a single keypress and does the job. With mouse dragging you need to do the (binary?) search yourself with your brain, each step having a significant roundtrip time between your brain and the computer, and what if the line is so wide that the scroll amount is much larger than the screen width? Then you have to go back to Ctrl+left/right for fine tuning. (Assuming the scrollbar would conventionally correspond to the whole width of the file, rather than to the width of the topmost line.)

We might have the infrastructure for displaying such a widget, but we don't know the overall width of the file in the viewer. It's tricky to implement because we don't scan the whole file now to be able to reasonably handle giant files.

• of course, it should not be the only way to access the feature, as mc is primarily keyboard-focused

This is definitely a valid point.

[ossi]

Replying to egmont:

Did I fail to provide a reason why scroll-past-eof is bad, really? I can only repeat myself,

try rebuking my arguments instead of repeating yours. because i already told you why i don't think they have any weight.

it could be ctrl-a/ctrl-e depending on whether you click in the left/right half of the screen. Any preference? (My weak vote goes for the second.)

yes, this is definitely better.

How would a horizontal scrollbar help you get quickly to the end of a particular line?

you make good points, but i'd argue that at a line length in the hundreds of columns (without extreme outliers), a scroll bar works much better than half-width stepping with the keyboard. that's practical experience with browsing qt (and other) build logs with less and firefox.

we don't know the overall width of the file in the viewer.

yes, it would have to be somewhat dynamic (using the max of the surrounding 1000 lines or something). while it's annoying due to the jumpiness, it works well enough in practice (not that i would remember now where i have actually seen it).

anyway, let's drop the scrollbar topic - the other solutions are better.

[andrew_b]

Fixed as part of #3250.