The top-left corner changing is far more conspicuous than the top right.

Allow the user to search in a help text with ^W and M-W.

Achieve this by not writing the help text directly to the screen
but first writing it to a temporary file and then opening this file
in a new buffer, and treating it specially: the normal file-reading
feedback is suppressed, the titlebar shows the headline of the text,
the cursor is hidden, and the menu is limited to just the up and down
movements and searching.

This fulfills https://savannah.gnu.org/bugs/?28994

.
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>

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

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.