Re: [Nano-devel] [RFC] vertical scroll arrows

[Brand Huntsman]

On Thu, 15 Mar 2018 21:19:49 +0100
Benno Schulenberg <address@hidden> wrote:

> the scroll thing shouldn't be visible in the file browser.

Fixed.

Unrelated, but there is a space after * in browser.c do_browse_from():
    char * currentdir = charalloc(PATH_MAX + 1);


> But the percentage... is strange.  When the buffer is short, just
> slightly bigger than the edit window (like for example the ^W help
> text), then the percentage goes for me from: arrow-down, 40%, 60%,
> 80%, arrow-up.  To me it is unclear what it means: when I press
> <Down> once, is then 40% of the text out of view?  And no, it is not
> right that the up-arrow appears *before* the last (blank) line of the
> text is in view -- that's probably the reason why it skips the 20%?

I assume your file is 4 lines longer (excluding the last blank line) than 
editwinrows. Subtracting 1 from both lineno's in pct calculation fixes this. 
You then get Top, 25%, 50%, 75%, Bot. The 75% means 3 of the 4 extra lines are 
scrolled off the top.

Assume the file contains 20 lines of text and the 21st line is blank. If 
editwinrows is 20, then scrollbar will be empty, because the entire file is 
displayed. The last blank line is irrelevant, I assume nano adds it to every 
buffer and never removes it. Counting that blank line means a down arrow would 
be displayed, even though the entire file is visible. And in the first example, 
when 4 lines are scrolled off the top the last blank line won't be visible yet, 
so we must display 100% in the scrollbar. Ignoring it gets rid of the 100% and 
excludes an irrelevant line from the count.


> Emacs works differently, it goes: Top, 7%, 7%, 12%, 17%, 20%, Bot.  It
> shows how much of the text has been scrolled off the top of the screen
> (characterwise, not linewise).

That doesn't make any sense, it gives no indication how far away the bottom is.