Also, do not break overlong lines and do not convert tabs to spaces,
nor interpret a <Tab> as an indent command (when the mark is on).
In other words: accept an outside paste as literally as possible.
This fulfills https://savannah.gnu.org/bugs/?40060.
Requested-by: Egmont Koblinger <egmont@gmail.com>
And fulfills https://savannah.gnu.org/bugs/?57527.
Requested-by: Sébastien Desreux <seb@h-k.fr>
Requested-by: Hans Ecke <hecke@gxt.com>
Original-idea-by: Brand Huntsman <alpha@qzx.com>
Also, tell the terminal to switch on bracketed-paste mode, and toggle
a boolean when the start and stop sequences of such a paste are seen.
This boolean can later be used to suppress auto-indent and such.
Signed-off-by: Brand Huntsman <alpha@qzx.com>
The file may not be modified when in View mode, so it makes no sense
to prominently show the M-J keystroke in the Search menu when in that
mode, especially since the keystroke does not really belong there.
This addresses https://savannah.gnu.org/bugs/?57574.
The extract() and copy_from_buffer() functions are mainly used for
cutting a line or a region, so move them to src/cut.c. Also move
the function for which copy_from_buffer() is a wrapper.
When suspending nano on a Linux console (or FreeBSD console), the
helpful message about using the 'fg' command overwrote the start
of the second help line, kind of hiding the message. So, output
a double newline before the message to make it stand out.
Also, drop a pointless cursor movement, as endwin() determines
the placement of the cursor all by itself.
Since the previous commit, USE_SLANG can only be defined when NANO_TINY
is also defined. This means that code that is present only in non-tiny
versions does not need to cater for Slang.
Slang contains bugs that get triggered when resizing the terminal,
or rather: when its existing data structures get reinitialized.
Avoid those bugs by forcing the exclusion of the resizing code
when nano is configured with --with-slang.
(The only reason for not entirely eliminating the support for Slang
is to allow Debian to build a tiny nano against Slang for on their
install image.)
This avoids https://savannah.gnu.org/bugs/?57520,
and avoids https://savannah.gnu.org/bugs/?57518,
and dodges https://savannah.gnu.org/bugs/?57513,
and dodges https://savannah.gnu.org/bugs/?57507.
With ncurses, a window resize will cause getch() to return immediately
with some dummy value, which nano can discard. But with Slang, getch()
will return only when the next keystroke is typed, so the received code
should then not be discarded.
This fixes https://savannah.gnu.org/bugs/?57507.
Use bolded HTML entities for the four arrows, instead of the literal
triangular Unicode "arrows" which many fonts don't include.
This addresses https://savannah.gnu.org/bugs/?57505.
The F13 to F16 function keys are no longer bound by default, and when
there is no nanorc file, there is no way to bind them, so there is no
point in recognizing their escape sequences.
Also, avoid calling a case-changing function when it's not needed.
And elide a default case that can never occur (because the function
always gets called with one of the four letters).
Nano does not do anything for the keystroke anyway (KEY_B2, the center
key on the numeric keypad, gets translated to ERR later on), so there
is no point in recognizing some of its escape sequences -- let those
sequences result in "Unknown sequence" instead.
When --rawsequences is used, consume the full escape sequences for
the F17 to F24 function keys (on xterm-compatible terminals and on
the Linux console), to prevent them entering junk into the buffer.
This fixes https://savannah.gnu.org/bugs/?57483.
When a line in a help text is wider than the terminal, then do not break
that line at COLS - 1, but simply at COLS. In olden times it made some
sense to have an empty column on the right of the introductory text, to
mirror the one on the left. But since the width of the introductions
got limited to 74 columns (four years ago, in commit a9aa0ef9), those
texts have (on a default 80-column terminal) at least six empty columns
on their righthand side. And on narrower terminals, we really don't
want to waste anything and should use all available space.
Also, this whole mechanism of making an exception for end-of-string or
end-of-paragraph and letting only those make use of the final column,
it was a waste of time: it kind-of did the whole break_line() process
again, but then for the entire string (which can be some five hundred
characters long in the introductory texts). So... get rid of it, make
it simple. On an 80-column terminal it doesn't make any difference.
When break_line() is called with its last parameter set to TRUE
(meaning that it will break also at a newline) it will return a
value that is bigger than 1. So it is pointless to ensure that
it is at least 1.
