Before this patch, when pasting over BUFSIZE (8192 bytes here), st would
do the following:

    \e[200~...8192 bytes...\e[201~\e[200~...remaining bytes...\e[201~

With this patch, the start marker is only sent when the offset is 0 (at
the beginning of selnotify) and the end marker is only sent when the
remaining bytes to read are 0 (at the end).

For short pastes, both conditions are true in the same iteration.

For long pastes, it removes the extra markers in the middle, keeping the
intended wrapping:

    \e[200~...8192 bytes......remaining bytes...\e[201~

Signed-off-by: Christoph Lohmann <20h@r-36.net>

gcc would warn about an unused result. We know it is 0 and dup()
can't fail in these circumstances, as we closed fd0 previously.
Using dup2() to do the same saves one line and shuts gcc up, bringing
us a clean build back.

The antialiasing was false due to circumstances that do not exist anymore. We
need antialiasing on big screens with big fonts. Autohinting too.

When a line has no any character linelen is 0, so last = &term.line[y][MIN(lastx, linelen-1)]
generated a pointer to the end of the previous line. The best thing we can do in this case
is to add a newline, because we don't have a glyph to print (and consult its state of
wrapping).

Signed-off-by: Christoph Lohmann <20h@r-36.net>

This configuration is basically 38400 8N1, without echo and
in raw mode. Kernel will not process any of the characters
sent by the user.

For completeness and documentation add all C1 control codes.

wcwidth() returns -1 for all the non visible characters, but it doesn't
necessarilly mean that they are incorrect. It only means that they are not
printable.

The current acsc entry, copied from xterm was not exposing capability to
display arrows.

A little fix in xwrite().

>From 3727d2e334 Mon Sep 17 00:00:00 2001
From: Quentin Rameau <quinq@fifth.space>
Date: Fri, 24 Jul 2015 11:40:46 +0200
Subject: [PATCH] Fix type for write(2) return variable.

The allocated lengh of s fits into an integer so we can safely use
ssize_t here.

This is needed so big input like a paste of several megabyte does not clog our
I/O.

Signed-off-by: Christoph Lohmann <20h@r-36.net>

and add a space between the keyword and the parentheses.

Signed-off-by: Christoph Lohmann <20h@r-36.net>

Put the opening brace on a new line. This was already used for some
functions inside st.c.

Signed-off-by: Christoph Lohmann <20h@r-36.net>

This practice proved itself in sbase, ubase and a couple of other
projects.
Also remove the True and False defined in X11 and FcTrue and FcFalse
defined in Fontconfig.

Signed-off-by: Christoph Lohmann <20h@r-36.net>

Any system having different assignments than the usual 0, 1, 2 for
the standard file numbers and 0, 1 for the exit-statuses is broken
beyond repair.
Let's keep it simple and just use the numbers, no reason to fall
out of the window here and bend down for POSIX.
In one occasion, the ret-variable was not necessary. The check was
rewritten.

Signed-off-by: Christoph Lohmann <20h@r-36.net>

This reverts commit d2937b05ae.

This reverts commit 7ab6c92e18.
We need 32 bits for real color support.

For a higher usefulness of the utf8strchr function, the index of the
UTF-8 character could be returned in addition with a Rune instead of a
char*.  Since utf8strchr is currently only used by ISDELIM I didn't
bother to increase the complexity.

Otherwise a tangling bmotion event will consider
the selection still valid and selnormalize segfaults
because of an invalid sel.ob.y index.

Here's a patch that fixes a bug when calling `makedrawglyphfontspecs'
in `drawregion'. Wasn't offseting the pointer into the input glyphs
array by `x1'. The bug isn't causing any problems currently, because
`drawregion' is always called with `x1' and `y1' values of 0, but if
this ever changes in the future, the bug would certainly cause some
problems.

I have another patch here for review that optimizes the performance of
glyph drawing, primarily when using non-unit kerning values, and fixes a
few other minor issues. It's dependent on the earlier patch from me that
stores unicode codepoints in a Rune type, typedef'd to uint_least32_t.

This patch is a pretty big change to xdraws so your scrutiny is
appreciated.

First, some performance numbers. I used Yu-Jie Lin termfps.sh shell
script to benchmark before and after, and you can find it in the
attachments. On my Kaveri A10 7850k machine, I get the following
results:

Before Patch
============

1) Font: "Liberation Mono:pixelsize=12:antialias=false:autohint=false"
   cwscale: 1.0, chscale: 1.0
   For 273x83 100 frames.
   Elapsed time :     1.553
   Frames/second:    64.352
   Chars /second: 1,458,159

2) Font: "Inconsolata:pixelsize=14:antialias=true:autohint=true"
   cwscale: 1.001, chscale: 1.001
   For 239x73 100 frames.
   Elapsed time :   159.286
   Frames/second:     0.627
   Chars /second:    10,953

After Patch
===========

3) Font: "Liberation Mono:pixelsize=12:antialias=false:autohint=false"
   cwscale: 1.0, chscale: 1.0
   For 273x83 100 frames.
   Elapsed time :     1.544
   Frames/second:    64.728
   Chars /second: 1,466,690

4) Font: "Inconsolata:pixelsize=14:antialias=true:autohint=true"
   cwscale: 1.001, chscale: 1.001
   For 239x73 100 frames.
   Elapsed time :     1.955
   Frames/second:    51.146
   Chars /second:   892,361

As you can see, while the improvements for fonts with unit-kerning is
marginal, there's a huge ~81x performance increase with the patch when
using kerning values other than 1.0.

So what does the patch do?

The `xdraws' function would render each glyph one at a time if non-unit
kerning values were configured, and this was the primary cause of the
slow down. Xft provides a handful of functions which allow you to render
multiple characters or glyphs at time, each with a unique <x,y> position,
so it was simply a matter of massaging the data into a format that would
allow us to use one of these functions.

I've split `xdraws' up into two functions. In the first pass with
`xmakeglyphfontspecs' it will iterate over all of the glyphs in a given
row and it will build up an array of corresponding XftGlyphFontSpec
records. Much of the old logic for resolving fonts for glyphs using Xft
and fontconfig went into this function.

The second pass is done with `xrenderglyphfontspecs' which contains the
old logic for determining colors, clearing the background, and finally
rendering the array of XftGlyphFontSpec records.

There's a couple of other things that have been improved by this patch.
For instance, the UTF-32 codepoints in the Line's were being re-encoded
back into UTF-8 strings to be passed to `xdraws' which in turn would then
decode back to UTF-32 to verify that the Font contained a matching glyph
for the code point. Next, the UTF-8 string was being passed to
`XftDrawStringUtf8' which internally mallocs a scratch buffer and decodes
back to UTF-32 and does the lookup of the glyphs all over again.

This patch gets rid of all of this redundant round-trip encoding and
decoding of characters to be rendered and only looks up the glyph index
once (per font) during the font resolution phase. So this is probably
what's responsible for the marginal improvements seen when kerning values
are kept to 1.0.

I imagine there are other performance improvements here too, not seen in
the above benchmarks, if the user has lots of non-ASCII code plane characters
on the screen, or several different fonts are being utilized during
screen redraw.

Anyway, if you see any problems, please let me know and I can fix them.