If CONTROL + INSERT inserts a line then it seems natural CONTROL + DELETE
removes a line.

The AppMode and AsciiMode were inverted in the definition of this
combination.

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

Before this patch draw() calls drawregion which calls xdraws and then
updates whole window in one call thus overdrawing anything drawn by
w3mimgdisplay. After moving XCopyArea to xdraws it only updates the
regions which are being updated by XftDraw* functions. It may do a few
more calls to XCopyArea with this patch.

Signed-off-by: Amadeusz Sławiński <amade@asmblr.net>

for example
echo -e "\e[48;2;255;0;0m\e[38;2;0;0;255m test "
should render on red bg with blue fg

also now elinks works correctly when using 'truecolor' option
in preferences

Signed-off-by: Amadeusz Sławiński <amade@asmblr.net>

Sorry for another duplicated mail. I found the patch is malformed
significantly. I've been away from my laptop for a while, so I'm quite
unfamiliar with the settings on this system...

sbase did some interesting modifications to arg.h (basically it
was fixed an incorrect use of the _ namespace), and this commit
take this last version for st.

This fixes a bug that the parent tty gets resized whenever you launch
st through command line.

The problem was that ioctl was resizing cmdfd before it gets
initialized in ttynew. Since cmdfd is a global variable, its initial
value is 0, and consequently stdin was being resized.

Shitf modifier adds 12 to the function number of the function keys,
while Control adds 24, so Control + F4 generates F28

rmul means "exit underline mode", so a full reset of all
the attributes is not the correct way of exiting from
underline mode, because it is going to modify also another
attributes not related.

Since st is using now int32_t and uint32_t the inclusion of
stdint or inttype is mandatory, because in other case the
definition of these new types will not be known by the
compiler.

k0ga misktook applying patch of others. Sorry guys!!!!

This patch replaces long by int32_t. It saves
some memory on 64bit systems.

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

Conflicts:
	config.def.h
	st.c

Use correct type for Mousekey.b (XButtonEvent.button).

vt100 has support for two defined charset, G0 and G1. Each charset
can be defined, but in each moment is selected only one of both
charset. This is usually used selecting a national charset in G0
and graphic charset in G1, so you can switch between graphic
charset and text charset without losing the national charset
already defined.

st hasn't support for national charsets, because it is an utf8
based terminal emulator, but it has support for graphic
charset because it is heavily used, but it only supports G0,
without understanding G1 selection sequences, which causes some
programs in some moments can print some garbage in the screen.

This patch adds a fake support for multiple charset definitions,
where we only support graphic charset and us-ascii charset, but
we allow more of one charset definition.

This patch allow define G0 until G3 charsets, but only accepts
select G0 or G1, and it accepts some national charset definitions
but all of them are mapped to us-ascii.

st was assuming that save/restore cursor position was independent
of the screen that was shown in each moment, but it is not true,
because each screen has a different save/restore buffer. This
patch fixes it.

OpenBSD 5.3 amd64 release version with the most current st
version from git, crash and dump core when selecting multiple
lines whith the cursor.  This happens, because on line 964
of st.c (gp-1)->mode is accessed, although gp is still
pointing at the beginning of the array term.line[y] (see
line 939 for initialization of gp).

This patch enables bracketed paste mode (
http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#Bracketed%20Paste%20Mode
).

It's mainly useful for text editors to disable line wrapping and auto
indentation when text is being pasted, rather than typed from keyboard.

On the emulator side, it is supported by at least xterm, urxvt,
gnome-terminal, putty, iterm2; and I have a patch for konsole.

On the application side, vim can be configured easily to handle this, and
I have pending patches for mcedit and joe. Probably many others also
support it.

* Button number in X10 mode:

  I believe the button - 1 came from "C b is button - 1" from [0].
  However, above this section, it states

    "Normally, parameters (such as pointer poisition and button number)
     for all mouse tracking escape sequences generated by xterm encode
     numeric parameters in a single character as value+32. For example, !
     specifies the value 1."

  Also, from the description of SGR,

    "The encoded button value in this case does not add 32 since that
     was useful only in the X10 scheme for ensuring that the byte
     containing the button value is a printable code."

  This suggests that we should still add 32 to the button value when in
  MODE_MOUSEX10.

* No button release reporting in X10 mode:

    "X10 compatibility mode sends an escape sequence only on button press,
     encoding the location and the mouse button pressed."

* Fix MODE_MOUSEMOTION:

  Currently, motion reporting is skipped when oldbutton == 3
  (corresponding to no button being pressed). However, oldbutton is
  only set on a button press, which will never be 3.

[0]: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html

\a is the character for bell, and st is only marking the window as urgent
if it is not active. This patch adds an audible bell which can be disable
with bellvolume variable.

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

Thanks "Eon S. Jeon" <esjeon@hyunmu.am>!

The alternate screen is not properly initialized when st starts. To see
this, set defaultbg in config.h to anything other than 0 (for example, swap
defaultfg and defaultbg), and run:

./st -e sh -c 'tput smcup; read'

You should see that the top-left 80x24 rectangle is black (or whatever
colorname[0] is), while the rest of the screen (if any) has the desired
colorname[defaultbg] color.

The attached patch fixes this by initializing term.c.attr in tnew() before
calling tresize(). It also removes the unnecessary xcalloc() calls, which
misled me on this bug hunt since it is really tclearregion() which
initializes term.lines and term.alt in tresize().

Hello.

I reviewed and tested commit 7e3cff3, and made a patch that fixes some
problems in it.

1. There's a semicolon after an if statement, which is obviously a
typo.

2. The current way of calculating text position in "xdraws" yields
inconsistent results in some cases. This is due to the use of
"font->width", which varies. Instead, "xw.cw" has to be used as the
character width.

Sincerely,
Eon

Thanks for noticing Fidel Barrera Cruz!

Some programs don't check the value of km and use smm and rmm
capabilites, and they cause the terminal change to meta enabled
mode even in cases where is not desirable.

Allmost all people is using the terminal waiting that meta sends
escape, so rmm and smm are not needed. If someone needs meta
sets 8 bit he can use the correct terminfo definition in TERM.

tdefcolor() returns -1 on error, while its return type is
unsigned long. At the same time, line 1724 and 1731 are checking the
positivity of its unsigned return value.

ATTR_BLINK is an attribute for a Glyph and will not be set in term.mode.

The bounding boxes for characters can be scaled using "cwscale" and "chscale"
to scale the width and height respectively.

Colors definition can be changed using a OSC sequence, so
we have to reload them if we want be sure all the colors
are the correct.

Could be desirable free the colors allocated due to rgb
colors and inverse colors (XftColorAllocValues in xdraws),
but it is impossible due we use the same structure for all
of them.

This patch uses the bit 24 in the color descriptor as an indicator
of RGB color, so we can take the values and generating the XftColour
directly in xdraws.

I made a patch that improves the performance of font caching mechanism.
This is based on a funny behaviour of FontConfig: it was handling
FcCharSet in a somewhat unexpected way.

So, we are currently adding "a character" to a new FcCharSet, and then
add it to a FcPattern. However, if we toss the FcPattern to FontConfig,
it loads the entire language(charset) that contains the character we
gave. That is, we don't always have to load a new font for each unknown
character. Instead, we can reused cached fonts, and this significantly
reduces the number of calls to extremely slow FontConfig matching
functions.

One more thing. I found that, in libXft, there's a function called
XftCharExists. XftCharIndex internally calls this function, and
does more stuffs if the character does exist. Since the returned index
is never used in st, we should call XftCharExists instead of
XftCharIndex. Please note that I already made this change in the patch.