Thanks to tarug0 for the suggestion/patch.

st currently does not keep any mode for the cursor that was active
in the underlying glyph (e.g. italic text), the mode is always
ATTR_NULL [1].  At [2] you can find a screenshot that shows the
implications.  Other terminals (at least vte-based, such as
XFCE-terminal) keep some modes for the cursor.  I find the current
behaviour very disruptive, so here is a patch that keeps a few
(arbitrarily chosen) modes for the cursor.

[1] http://git.suckless.org/st/tree/st.c#n3963
[2] http://i.imgur.com/R2yCEaC.png

This is used by, e.g., tmux.

CTRL+SHIFT is an impossible combination in the terminal world
(0x20 | x & 0x1F), so it is perfect to be used for internals
shortcuts of terminals, and being a double combination
reduces the prossibility of having comflicts.

This reverts commit 424202798b.

XftFontMatch does display-specific font configuration (commit 528241a).
Nice. Unfortunately, when we switched from FcFontMatch, we also stopped
storing the post-Fc{Config,Default}Substitute FcPattern for future
lookups. The result is that if a glyph isn't found in the primary font,
secondary font lookups use the original FcPattern, not the configured
one. If you have custom fontconfig rules (like me), this can be
disappointing.

I basically just copied the guts out of XftFontMatch[1] and saved
the intermediate configured FcPattern. Could be related to the bug that
inspired commit 4242027.

[1]: https://cgit.freedesktop.org/xorg/lib/libXft/tree/src/xftfont.c

When using st with screen, I've bound next, prev, new screen to
combinations like Ctrl-Alt-Right,Left,Down; xterm and (u)rxvt work fine
when this combination of modifiers is pressed, st does not seem to
transport all of them; a single modifier key is fine (e.g. Ctrl-Up,
Alt-Down etc., but combinations are not). While I'm not terribly
familiar with this, I have tried to hack config.h in a more or less
systematic way to generate the expected sequences.

Hi,

When I specify a font by point size (I'm using "Inconsolata:size=12"),
characters that are substituted from another font because they are not in the
main one appear too small.  Doing a zoom reset fixes it.  For example:

Before: http://i.imgur.com/G4Mfv4X.png
After:  http://i.imgur.com/PMDhfQA.png

I found that adding the pixel size (acquired from the initial font load) to the
pattern then reloading the font fixes the problem.  I'm not sure if this is a
proper fix, though.

The two functions strdump(), csidump() are called to show errors and
their output is introduced by a message printed to stderr. Thus, it it
more consistent to have them print to stderr.

Moreover stderr is unbuffered (at least on Linux), making problems
immediately visible.

If fontconfig gives us a font without the attributes we asked for,
display an alternative color instead.

We launch dmenu for getting a codepoint, then convert it and send it to
the terminal.

Also, it's ttyS0 not ttySO.

These sequences are used to operate with sixels, but they are still
str sequences, so they are finished with \a, ST or with a C1 control
code. This patch also disables utf8 handling for the case of sixels.

There are some ocasions where we want to disable the enconding/decoding of utf8, mainly
because it adds an important overhead. This is partial patch for ESC % G and ESC % @,
where they modified the way that st reads and write from/to the serial line, but it does
not modifies how it interacts with the X window part.

We do not need to disable the previous ncv definition, because
there is not previous definition.

With ncv set to 3, we prevent st from displaying A_STANDOUT and
A_UNDERLINE with colors while our virtual terminal is capable of it.

This is for the next release.

If you don't make sure that the terminal does not expand tabs to spaces, of
course such a setting won't work.

st.info needs to be changed too, when tabspaces are changed.

The default config specifies BackSpace as "\177". The default behavior
should persist across modifier keys, commonly Mod1 (Alt or Meta) which
is widely used to delete a word on readline and text editors, notably
Emacs.

This will make Alt+BackSpace behaves as expected, i.e. sends "\033\177"
instead of "\033\010" as previous default behavior.

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

git am -s didn't like your patch:

From: Mark Edgar <medgar123@gmail.com>

XftFontMatch calls XftDefaultSubstitute which configures various match
properties according to the user's configured Xft defaults (xrdb) as well as
according to the current display and screen. Most importantly, the screen DPI
is computed [1]. Without this, st uses a "default" DPI of 75 [2].

[1]: https://cgit.freedesktop.org/xorg/lib/libXft/tree/src/xftdpy.c?id=libXft-2.3.2#n535
[2]: https://cgit.freedesktop.org/fontconfig/tree/src/fcdefault.c?id=2.11.1#n255

https://tronche.com/gui/x/icccm/sec-2.html#s-2.4 specifies:
> Once all the data in the selection has been retrieved,
> the requestor should delete the property in the SelectionNotify request

Most Clipboard-Owners ignore whether or not the property is already set,
so this is mostly a cosmetic change to keep the windows property list clean.

However, at least synergy decides to wait for the requestor to delete
the properties if they are already set by a previous paste (from synergy).

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

LEN(str) is one larger than strlen(str) because it also counts the zero
terminator. The original code would include the .notdef glyph (since it'll
try to encode character 0, which gets encoded to the .notdef glyph) when
measuring the average dimensions of printable ascii characters.

This causes problems with fonts like GNU Unifont where the .notdef glyph is
not the same width as the usual half-width characters.

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

The y-position of a character found by asking fontconfig for a matching
font does not take the border pixels into account, resulting in a
slightly misaligned vertical position.

Signed-off-by: Ton van den Heuvel <tonvandenheuvel@gmail.com>
Signed-off-by: Christoph Lohmann <20h@r-36.net>

This fix is needed to use dual-width fonts, which have double-width
glyphs (e.g. CJK unified ideographs).

Signed-off-by: Ryusei Yamaguchi <mandel59@gmail.com>
Signed-off-by: Christoph Lohmann <20h@r-36.net>

Thanks Ton van den Heuvel for the proposal!

This prevents accessing to a potentially out-of-bounds memory section.

Signed-off-by: Lucas Gabriel Vuotto <l.vuotto92@gmail.com>
Signed-off-by: Christoph Lohmann <20h@r-36.net>

Scratch the preceding patch, this one is more correct
(don't forget to 'git am --scissors' ;))
-- >8 --

Also reformat the strings in a saner layout

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

This way we can call cresize() to set the terminal size before creating
a tty or spawning a process, which will start with the correct size.

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

This is just redundant metadata. Please add Java comment meta classes too.

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

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

dvtm is too fast in starting up. It will then have a race condition in finding
the right. terminal size.

Ttyread() calls to ttywrite, so if we check for reading before
that for writing in ttywrite we can get a circular call sequence.

ARGUM isn't used and ARGNUMF uses estrtol() that isn't defined anywhere.
Those were probably copied from sbase arg.h.

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

ttywrite was assuming that if it could not write then it could
read, but this is not necessarily true, there are some situations
where you cannot read or write. The correct behaviour is to detect
if you can read or/and write.