id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,blockedby,blocking,branch_state,votes 3256,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.",defect,closed,major,4.8.14,mcview,master,fixed,,,,,no branch,