The go_back_chunks() function will do this clipping.

This fixes https://savannah.gnu.org/bugs/?50866.

It takes almost no code and is a useful little improvement over Pico.

Because nothing gets reset to zero or to some initial value.

To avoid an ncurses hiccup (miscoloring) when running on musl.

This fixes https://savannah.gnu.org/bugs/?50787

.
Reported-by: Avi Halachmi <avihpit@yahoo.com>

The cursor needs to be placed in its proper spot in the edit window
/only/ when nano is about to accept input from the user and needs to
show where this input will go.

(This might cause a scrolling issue to appear, because reset_cursor()
does not just place the cursor, it also recomputes current_y, which
is used in several places to determine whether and how much to scroll.
If it so happens, we'll deal with that fallout later.)

The interval 2013-2017 for the Free Software Foundation is valid
because in those years there were releases with changes by either
Chris or David, and the GNU maintainers guide advises to mention
a new year in all files of a package, not just in the ones that
actually changed, and be done with it for the rest of the year.

Make nano recognize the escape sequences for Ctrl-Home, Ctrl-End,
Shift-Ctrl-Home, and Shift-Ctrl-End on xterm, rxvt, and Eterm.

On some terminal emulators, Ctrl+Home and Ctrl+End produce special
keycodes, distinct from plain Home and End.  Make the users of those
emulators (and of the Linux console) glad by making ^Home and ^End
do the obvious thing, and the combinations with Shift too.

When a multi-column character straddles a chunk boundary, and the
preferred column (placewewant) for the cursor is zero, cheat: show
the cursor not where the character starts but on the beginning of
the next row.  This makes the cursor move smoothly in the leftmost
column of the screen when using <Up> and <Down> and such, instead
of jumping around.

In this way the scrolling logic won't get confused and the screen
will scroll properly when stepping beyond the top or bottom row.

This fixes https://savannah.gnu.org/bugs/?50687.

This fixes https://savannah.gnu.org/bugs/?50741.

Verify at startup that the number is not too small.

If edittop is partially offscreen before we scroll, and it gets
scrolled more offscreen, we do need to compensate for the chunks
between firstcolumn and leftedge -- that is: the chunks between
the top row and the cursor row.

This fixes https://savannah.gnu.org/bugs/?50691.

When a two-column character cannot be shown because it straddles the
boundary between two chunks of a line, show the '>' placeholder for
its left "half", and '<' for its right "half".

This mitigates https://savannah.gnu.org/bugs/?49440.

The leftedge variable is a column number, not an x position.

The number of rows to draw shouldn't be compensated for the chunks
of edittop that are before firstcolumn, because they are offscreen.

This completes the fix for https://savannah.gnu.org/bugs/?50621.

There is no need to always increase nrows by 1 or 2 -- an increase
of 1 is only needed when the line that borders on the scrolled region
needs to redrawn too: when this line was horizontally scrolled or when
the mark is on.

This fixes https://savannah.gnu.org/bugs/?50621

.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>

But apparently none of these cases occur, because I can't trigger them.

This could happen when a tab or a double-width character straddles
the boundary between two softwrapped chunks.

If the number of columns in the edit window changes (which currently
only happens in two places: in regenerate_screen(), called when the
window is resized; and in main(), when line numbering mode is toggled),
the display will break if we're in softwrap mode and firstcolumn is
nonzero.  This is because the column width of softwrapped chunks has
changed, and firstcolumn is no longer the starting column of a chunk,
an assumption that all code using firstcolumn relies on.

To fix this problem, add a new function, ensure_firstcolumn_is_aligned(),
to adjust firstcolumn to the starting column of the chunk it's on, and
use it when the number of columns in the edit window changes.

(Note that this function uses the simplest possible fix, and could
probably be made more sophisticated.)

The new function, update_softwrapped_line(), is called from inside
update_line() when softwrap mode is on, so that existing calls remain
unchanged.  It takes no index, instead displaying edittop from column
firstcolumn, and all other lines from column zero.

If current is on edittop, it's displayed using the edittop rules, but
this is not a problem: if current[current_x] is above edittop at column
firstcolumn, it's offscreen, and that should be handled before calling
update_line() anyway.

Together with the preceding bunch of changes,
this fixes https://savannah.gnu.org/bugs/?47667.

When counting rows in softwrap mode, reset_cursor() should compensate for
the number of softwrapped chunks that edittop takes up before firstcolumn.

Make current_is_above_screen() check for current[current_x] being above
edittop at column firstcolumn, and make current_is_below_screen() start
counting down from edittop at column firstcolumn instead of edittop at
column zero.  This means that both functions now account for softwrapped
chunks properly.

Actually enable scrolling edittop partially off the screen by making
edit_scroll() and adjust_viewport() use firstcolumn properly when
iterating through softwrapped chunks in softwrap mode, or lines in
non-softwrap mode.

In non-softwrap mode, firstcolumn should still always be zero, because
it's initially set to that, and because passing it through the iterators
will maintain it at that.

This fixes https://savannah.gnu.org/bugs/?49100

.
Reported-by: David Lawrence Ramsey <pooka109@gmail.com>

Since all lines can be partially scrolled off the screen now
(except for edittop, which is forthcoming), the maxlines global
variable and its computation mechanism are no longer needed.

Use go_back_chunks() to adjust edittop, instead of special casing
the computation of goal when softwrapping.  Now softwrap mode and
non-softwrap mode will behave the same way when edittop can be
partially scrolled off the screen, which is forthcoming.

(Note that the top line of the screen can't be partially scrolled
yet, so we have to work around that for now.)

Use go_back_chunks() and go_forward_chunks() to adjust edittop and to
move up or down to the scrolled region before updating the rows there.
Now softwrap mode and non-softwrap mode will behave the same way when
we can scroll the top line of the screen partially off the screen,
which is forthcoming.

(Note that the top line of the screen can't be partially scrolled yet,
so we have to work around that for now.)

Not drawing a line on a row if we're on the top row and scrolled down,
or if we're on the bottom row and scrolled up, will only work properly
if the line on that row takes up only that row.  The latter might not
be the case in softwrap mode: if the line occupies multiple chunks and
begins on that row -- in that case none of the chunks would be drawn.

The old name made it sound as if it didn't apply in softwrap mode.  But
it does: in softwrap mode a line needs updating  when the mark is on.

Add the new functions current_is_above_screen() (which doesn't account
for softwrapped chunks yet, but will when we can scroll edittop partially
off the screen, which is forthcoming), current_is_below_screen() (which
determines whether current[current_x] is past the softwrapped chunk at
the bottom of the screen), and current_is_offscreen() (the union of the
previous two functions).

edit_redraw() and edit_refresh() now use current_is_offscreen() to check
whether they should adjust the viewport, and adjust_viewport() now uses
current_is_above_screen() to determine whether current is on or below
the screen in FLOWING mode.

Add the new function less_than_a_screenful() to accomplish this.
It uses go_back_chunks() to count the number of softwrapped chunks
between the end point and the starting point of the paste.

Now softwrap mode and non-softwrap mode behave the same way when
uncutting fewer than editwinrows rows of text.  Accordingly, remove
the call to ensure_line_is_visible(), as it no longer applies.

These functions, go_back_chunks() and go_forward_chunks(), take a number
of softwrapped chunks (screen rows) to move, a pointer to a buffer, and
a location (specifically, a starting column of a softwrapped chunk).  If
they move successfully, they will update the buffer pointer and location
to point to the beginning of the softwrapped chunk they moved to.

Since non-softwrap mode is effectively just a subset of softwrap mode
in which every line takes up one chunk, these functions also work in
non-softwrap mode.  In this case, their starting column will always be
zero, as it would be in softwrap mode on a line that takes up one chunk.

Nothing uses these functions yet, but that is forthcoming.