Re: [Nano-devel] Proposal: Change how nano navigates softwrapped lines

[Benno Schulenberg]

On Tue, Dec 13, 2016, at 02:44, David Ramsey wrote:
> I propose the following way to deal with how nano moves through a file
> in softwrap mode, based on how other editors with softwrap behave,

Which other editors are those?  Vim (when doing softwrap, which
appears to be its default) moves vertically like nano: by logical
line, not by screen line.  You have to use special key sequences,
gj and gk, to move by screen line.  Emacs does move by screen line
by default (and it nicely indicates that lines are softwrapped too),
and I must say that I like that.

Several other editors (joe, geany) behave like nano in its default
mode: overlong lines simply run off the screen.  Gedit softwraps
by default (and is careful to break only at whitespace, not in the
middle of words) and moves by visual line, not logical ones.  Yes,
it is the best behavior, in my opinion.

> Changes should be made to the following functions: up and down, pageup
> and pagedown, and scroll-up (M--) and scroll-down (M-+).  These should
> be the only functions changed

What should <Home> and <End> do?  Move to the start and end of the
logical line (instead of screen line) like in Emacs, which is kind
of surprising?  (But... I agree that it is the best option.)  Gedit
makes <Home> and <End> act on visual lines.

> The changes should be as follows:
> 
> 1. Instead of moving through a softwrapped line in its entirety, which
> may take up several lines on screen, up and down should move a single
> virtual softwrapped line, which will always take up a single line on
> screen.

Good.

> 2. Instead of moving through softwrapped lines in their entirety until
> they've moved an entire page's worth of lines, pageup and pagedown
> should move an entire page's worth of single softwrapped lines.

This will make a <PageUp> following a <PageDown> return to the
same place in the file (if there was enough room to move), which
is good, because currently the behavior of such a sequence is
often confusing.  But this already implies that it is not always
edittop that points at the top-left corner of the screen, but
sometimes "edittop plus a multiple of editwincols".

> 3. Instead of scrolling through a softwrapped line in its entirety,
> which may take up several lines on screen, scroll-up and scroll-down
> should move a single virtual softwrapped line, which will always take
> up a single line on screen.

Good.  And the same implication as above.

> These changes will eliminate the need to always keep the softwrapped
> line the cursor is on entirely onscreen, which should fix the
> aforementioned inconsistencies, and will ensure that nano no longer
> becomes unusable in the case of a softwrapped line that takes up more
> than one screenful (bug 49100).  They will also make it easier to
> navigate through overly long lines vertically, which should save time.

Fine by me.  Is there anyone who wants to hold on to the
current behavior?  Because I don't want to make the new
behavior an option -- it will simply be the way softwrap
behaves.

Benno

-- 
http://www.fastmail.com - Choose from over 50 domains or use your own