Re: [Nano-devel] RFC: change the behavior of the two scrolling commands (M-- and M-=)?

[Brand Huntsman]

On Sun, 11 Mar 2018 13:31:48 +0100
Benno Schulenberg <address@hidden> wrote:

> > I also wanted to add a key that scrolls cursor to center of
> > window.  
> 
> I have a patch for that, posted a long while ago [1].  It has evolved
> a bit since then, integrating it into the ^L (refresh) function so it
> doesn't need a separate key.  I'll have to grab it off the old laptop
> and update it for the current situation, and will repost.

Thanks for the patch. I have only used ^L when a bug report tells me to use it 
and when nano had the A_BANDAID syntax highlighting issues. I don't know how 
many people might use it regularly to fix terminal issues, but moving cursor 
and scrolling might be annoying for them. So this probably shouldn't be bound 
to ^L by default.

The only problem is the total_refresh() that flickers the screen and messes up 
my eyes for several seconds. It is worse with default titlebar color but is 
still quite noticeable with my dark gray titlebar. Changing the total_refresh() 
to edit_refresh() makes it work perfectly. Why does total_refresh() cause the 
edit window text to flicker but edit_refresh() doesn't? A "set 
totalrefreshoncenter" could exist for anyone who wants to bind it to ^L and not 
rebind total_refresh to another key. But having a useful feature flicker the 
screen could be a more serious issue for anyone with seizures.

The center/top/bottom option is also nice.


> > And/or a toggle mode that keeps cursor from changing lines in the
> > window. You press enter or down arrow and the text scrolls to keep
> > cursor on same line in window. This would be better than a key to
> > center the view because it always keeps the view centered on any
> > line you choose, which doesn't need to be the middle of the window.
> > I haven't written a patch yet to see if it would be annoying, but
> > it sounds good in theory.  
> 
> At my uni they had an editor that worked like that: the cursor was
> always on the center line of the screen.  It worked.  But it also
> meant that you could never have a full page of preceding text in
> view while adding more on the bottom line.  Your proposed mechanism
> would allow that.  Sounds interesting, but...

Was it annoying to have the text scroll every time you pressed enter? My 
biggest problem is doing all the work and finding out it is annoying to use. 
But it would basically rebind the up/down arrow keys to do_scroll_up/down. And 
that would be useful for reading files and a command line option to enable it 
with view mode would be nice. So it might still be useful even if annoying to 
edit with.