mcview Down/PageDown/End weirdnesses #3256
Comments
If anyone wants to give it a try, it's implemented at https://github.com/egmontkob/mc-3250 (c8c8486) |
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.)» |
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.
now, there are two arguments against scrolling past the end:
i'll continue the discussion about the cursor problem in #3250. |
Replying to ossi:
Simiarly, from a near-top position a pageup followed by a pagedown doesn't take you back there either. So it *is* symmetrical.
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).
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.
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. |
Replying to egmont:
yes, symmetry in one place, non-symmetry in another. point proven.
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".
total nonsense, and you know that.
that's a non-sequitur to the "being different" argument.
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.
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. |
Replying to ossi:
I really don't understand you at this point.
Wow, so the "end" of the document is defined by the means you're navigating?
Yeah I know, exactly the kind of nonsense as scrolling beyond EOF.
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?
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.
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.
What are the problems with search in my current version, again? I can't remember you mentioning any bug, sorry if I missed it. |
Replying to egmont:
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.
we are discussing the presentation of the end of the document, not the end of the document.
the pagedown button introduces the concept (in an obviously dynamic way).
i actually have considered that as a solution to providing context in front of a hit - remember "whole slew of new weirdness"? yes, that.
because they don't need to. you also don't need to if you solve the other problems adequately.
flowed == automatically wrapped.
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. |
Replying to ossi:
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.
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?
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!
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.
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.) |
Replying to egmont:
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).
the fact that you consider it a joke doesn't change the fact that i seriously considered the option and its implications.
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.
correct, because that usually indicates just bad page design.
they do ... the mouse.
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.
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.
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. |
Replying to ossi:
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.
I bet you've also seen log files, stack dumps etc. in browsers, haven't you?
Jumping to the end of a particular line with the mouse in browsers is hardly any easier than using Ctrl+Right in mcview.
So, do I summarize it correctly below?
I would still *hate* to tailor the scroll boundaries to please such an insignificant and hardly known feature of mcview. |
Replying to egmont:
i actually *said* i did.
depends on how often you need to click ctrl-right. and then ctrl-left. and then again ... you get the idea. i hope.
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.
correct.
that's an interesting idea for mouse-based navigation. but:
completely unviable for the purpose of quick & convenient navigation.
nope |
Replying to ossi:
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.
Okay I think this will the approach then.
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.)
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.
This is definitely a valid point. |
Replying to egmont:
try rebuking my arguments instead of repeating yours. because i already told you why i don't think they have any weight.
yes, this is definitely better.
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.
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. |
Important
This issue was migrated from Trac:
egmont(@egmontkob)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:
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:
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.
The text was updated successfully, but these errors were encountered: