Helps Vim (and hopefully others) to discover that this feature exists
without further user configuration.

It is unclear if it's "required" to do this on RIS, but it's useful when
calling reset(1) after interactive programs have crashed and garbled up
the screen.

FWIW, other terminals do it as well (tested with XTerm, VTE, Kitty,
Alacritty, Linux VT).

Consider the following example:

    printf '\e[?7l';\
    for i in $(seq $(($(tput cols) - 1))); do printf a; done;\
    printf '🙈\n';\
    printf '\e[?7h'

Even though MODE_WRAP has been disabled, the emoji appeared on the next
line. This patch keeps wide glyphs on the same line and moves them to
the right-most possible position.

Fixes garbage selections when switching to/from the alternate screen.

How to reproduce:

-   Be in primary screen.
-   Select something.
-   Run this (switches to alternate screen, positions the cursor at the
    bottom, triggers selscroll(), and then goes back to primary screen):

        tput smcup; tput cup $(tput lines) 0; echo foo; tput rmcup

-   Notice how the (visual) selection now covers a different line.

The reason is that selscroll() calls selnormalize() and that cannot find
the original range anymore. It's all empty lines now, so it snaps to
"select the whole line".

dc.collen is the length of dc.col, not the maximum index, hence if x is
equal to dc.collen, then it's an error.

With config.def.h, the last valid index is 259, so this correctly
reports "black":

    $ printf '\033]4;259;?\e\\'

260 is an invalid index and this reports garbage instead of printing an
error:

    $ printf '\033]4;260;?\e\\'

The Makefile used to suppress output (by using @), so this target made sense at
the time.

But the Makefile should be simple and make debugging with less abstractions or
fancy printing.  The Makefile was made verbose and doesn't hide the build
output, so remove this target.

Prompted by a question on the mailing list about the options target.

Under insert mode, when inserting a normal character in front of
a wide character, the affected region is shifted to the right by
one cell. However, the empty cell is reset as if being a part of a
wide character, causing the following cell being mishandled as a
dummy cell.
To reproduce the bug:
	printf '\033[4h' # set MODE_INSERT
	printf 妳好
	printf '\033[4D'
	printf 'x'
	printf '\033[4l\n'

Ignore processing and printing C1 control characters in UTF-8 mode.
These are in the range: 0x80 - 0x9f.

By default in st the mode is set to UTF-8.

This matches more the behaviour of xterm with the options -u8 or +u8 also.
Also see the xterm resource "allowC1Printable".

Let me know if this breaks something, in most cases I don't think so.

As usual a very good reference is:
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

"VT100 defines an escape sequence [1] called Device Status Report (DSR). When
the DSR sequence received is `csi 5n`, an "OK" response `csi 0n` is returned.
This patch adds that "OK" response.

I encountered this missing sequence when I noticed that fzf [2] would clobber
my prompt whenever completing a find.

To test that ST doesn't currently respond to `csi 5n`, use fzf's shell
extension in ST's repo to complete the path for a file.

    my-fancy-prompt $ vim **<tab>
    <select a file>
    st.c

Select a file with <enter>, and notice that fzf clobbers some or all of your
prompt.

After applying this patch, do the same test as above and notice that fzf has no
longer clobbered your prompt by placing the file name in the correct position
in your command.

    my-fancy-prompt $ vim **<tab>
    <select a file>
    my-fancy prompt $ vim st.c

Thank you for considering my first patch submission.

[1] https://www.xfree86.org/current/ctlseqs.html#VT100%20Mode
[2] https://github.com/junegunn/fzf
"

Patch slightly adapted with input from the mailinglist,

Adapted from (garbled) patch by wim <wim@thinkerwim.org>

Additional notes: it should reset all the colors using xloadcols().
To reproduce: set a different (theme) color using some escape code, then reset
it:

	printf '\x1b]104\x07'