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

[David Ramsey]

On Tue, Dec 13, 2016 at 9:29 AM, Benno Schulenberg
<address@hidden> wrote:
> Which other editors are those?

I was thinking of xfce's mousepad when it was around, Juffed, and KWrite
when its softwrap mode is on.

> 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.

Good to know.  I haven't used vim much. If I were that much into
vi-based editors, I probably would have switched from nano by now :)

I'm not sure about adding special key sequences for screen line versus
logical line movement.  We seem to be running out of keys for things,
and if they get added, someone down the line will probably request other
keys for other types of screen line versus logical line movement, and if
those get in the problem will only get worse.

> 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.

Good to know.  Indicating softwrapped lines may be more difficult with
the current code, since they leave no room for indicating that they're
softwrapped.  Unless something like the line numbering code gets adapted
for 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.

Good to know.  Whitespace would be a good visual breaking point in the
long term, but let's fix the navigational problems before we start
tackling the visual ones.

> 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.

I'd prefer logical lines instead of screen lines here.  I really could
go either way (KWrite has <End> move to the end of the screen line, and
if you press it again while there, the end of the logical line; ditto
for <Home>), but the interaction with smart home mode might be too weird
in the case of screen lines if, say, the wrapping coincidentally happens
to put spacing at the beginning of a given screen line.

> 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".

Indeed.