When parsing a line and a column number, of course the found values
need to be passed back, otherwise it would be pointless to parse them.

And in the bargain show an error message when doing ^R unreadabledir ^T.

Precalculation of the multiline color data can be cut short when the
user is impatient and starts typing.  But this would drop the first
byte of whatever was typed -- not nice when it was just plain text,
but surprising and worse when the first keystroke was a command.

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

When for a multiline syntax-coloring rule the starting regex matches at
the exact same spot as the ending regex, do a second round of resets, so
that reevaluation starts further back and gets a few more things right.

This mildly fixes https://savannah.gnu.org/bugs/?47420.

When we get a ^J as verbatim input, it is not possible to include it
into the file buffer or the prompt answer, because this would mean
adding an encoded null to the buffer or answer, and that is not what
the user intended.  One option would have been to simply ignore a ^J
in verbatim input.  But the choice has been made to act the same way
as when the ^J (0x0A) is found in the file data: start a new line.

That is the same response as to the Enter key, yes -- but the code
for the Enter key is ^M (0x0D), not ^J.  So, to be more precise,
rename the relevant variable from 'got_enter' to 'got_newline'.

When the user tab-completed a name at the Go To Directory prompt, this
name will end in a slash.  Remove this slash, so the name can be found
in the file list (where directory names don't include the final slash).

This fixes http://savannah.gnu.org/bugs/?48353

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

And order them from smallest stride to biggest stride.

So, slightly speed up the functions that check for those.

Invalid multibyte sequences get depicted with the Replacement Character,
and unassigned codepoints are shown as if they were a space.  Both have
a width of one.

Spaces and tabs and control codes never are multi-column glyphs, so
only look up the width for "normal", visible characters.

This avoids having to null-terminate every single-byte character.

Just allocate ample space up front and thus discard the delaying 'if' for
each and every character.  In most cases this will allocate far too much,
but that hardly matters: it is freed again as soon as the line is printed.

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

(The fix is slightly wasteful; speeding things up will follow later.)

Use knowledge of UTF-8 instead of converting to wide characters first.

Any control character is represented by a ^ plus an ASCII character.

Instead of showing the upper control codes like this:

   ^À ^Á ^Â ^Ã ^Ä ^Å ^Æ ^Ç ^È ^É ^Ê ^Ë ^Ì ^Í ^Î ^Ï
   ^Ð ^Ñ ^Ò ^Ó ^Ô ^Õ ^Ö ^× ^Ø ^Ù ^Ú ^Û ^Ü ^Ý ^Þ ^ß

show them like this:

   ^` ^a ^b ^c ^d ^e ^f ^g ^h ^i ^j ^k ^l ^m ^n ^o
   ^p ^q ^r ^s ^t ^u ^v ^w ^x ^y ^z ^{ ^| ^} ^~ ^=

The lower control codes continue to be shown like this:

   ^@ ^A ^B ^C ^D ^E ^F ^G ^H ^I ^J ^K ^L ^M ^N ^O
   ^P ^Q ^R ^S ^T ^U ^V ^W ^X ^Y ^Z ^[ ^\ ^] ^^ ^_

The representation of DEL (0x7F) continues as ^?.

Further, use knowledge of UTF-8 to avoid a roundtrip through
wide characters.

This fixes the second part of https://savannah.gnu.org/bugs/?48331

.
Reported-by: Mike Frysinger <vapier@gentoo.org>

This fixes the first part of https://savannah.gnu.org/bugs/?48331

.
Reported-by: Mike Frysinger <vapier@gentoo.org>

This fixes https://savannah.gnu.org/bugs/?47962 reported by Cody Taylor.

By removing from their main loops a condition that occurs just once.

Do the casting from integer to character rightaway in the first
intermediate buffer.

Just like when reading a file fails.  It needs the user's attention.

So we don't have to remember its awkward target name.

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

.
Reviewed-by: Benno Schulenberg <bensberg@justemail.net>
Signed-off-by: Rishabh Dave <rishabhddave@gmail.com>

Keystrokes are single integers (aided by the flags meta_key and
func_key) but in the input stream they can be encoded as escape
sequences (a series of bytes).  Characters are values in byte
range, but in UTF-8 one character can consist of multiple bytes.

Also rename two variables, because the secondary input buffer
that they refer to contains only characters (mostly just one),
never any shortcuts; and there are too many "kbinput" already.