aetf / libtsm

Terminal-emulator State Machine

TSM - Terminal Emulator State Machine

TSM is a state machine for DEC VT100-VT520 compatible terminal emulators. It tries to support all common standards while keeping compatibility to existing emulators like xterm, gnome-terminal, konsole, ...

This is a personal modified version. For more information, please refer to its original README.

Added feature

• More color palettes:
  • soft-black
  • base16{-light,-dark}
  • solarized{,-black,-white}
  • custom: set via API
• Support underline/italic rendering (with a patched version of kmscon)
• Support 24-bit true color
• Support Ctrl + Arrow keys
• Support custom title using OSC
• Bug fixes:
  • Repsonse to 'CSI c' contains random bytes
  • Fix invalid cpr values

Build

mkdir build && cd build
cmake ..
make
make install

Build options

Options may be supplied when configuring cmake:

cmake -DOPTION1=VALUE1 -DOPTION2=VALUE2 ..

The following options are available:

Name	Description	Default
BUILD_SHARED_LIBS	Whether to build as a shared library	ON
BUILD_TESTING	Whether to build test suits	OFF
ENABLE_EXTRA_DEBUG	Whether to enable several non-standard debug options.	OFF
BUILD_GTKTSM	Whether to build the gtktsm example. This is linux-only as it uses epoll and friends. Therefore is disabled by default.	OFF

Dependencies

• cmake >= 3.5
• xkbcommon-keysyms.h from xkbcommon (Optional. Will use private copy if not found.)

The test suits needs:

• check >= 0.9.10

The gtktsm example needs:

• gtk3
• cairo
• pango
• xkbcommon

libtsm's Issues

Make it compile on Windows

Out of the box libtsm doesn't compile on Windows.

There is a patch by RadAd, though. When cherry picked into a current version of libtsm it worked flawlessly for me.

RadAd@f879875

It would be great if this could be merged. Being able to build libtsm on Linux, macOS and Windows without the need to make any modifications to the code and the cmake files would be awesome.

If some improvements need to be made before merging I'm ready to volunteer.

Cursor never moves forward when mixing autocomplete and emoji

Yes, this is a weird-as-crud bug. I found it while working on my terminal emulator.

Basically:

• Make sure you're using a shell that tries to autocomplete your history by showing a shadowed version right after the normal text. This includes stuff like Xonsh or zsh + oh my zsh. If that doesn't make sense, here's a screenshot:
  

  Notice the shadowed autocomplete text.

• Open up a normal terminal emulator (or pretty much any one that supports copy/paste) and paste the following line:

  echo 🤔
  

• Now that it's been saved to your history, open up gtktsm or any other terminal emulator that uses libtsm. When you enter the letter e and the autocomplete fills in the rest of the line, the cursor will never move forward. Hit backspace, e, backspace, e, over and over again, and you can literally erase the entire line.

This is weird...

loose parser

i was probing so-called "key modifiers" capability that is implemented in xterm, its escape sequence is

\x1B[?0m
\x1B[?1m
\x1B[?2m
\x1B[?4m

the terminal started underline everything, means those ? ignored and request is treated as graphical

Don't hardcode color palettes, make them comfigurable

The current way is of course very unscalable...

libtsm fails to build with musl libc on Alpine Linux

this trivial patch

diff --git a/external/wcwidth/wcwidth.h b/external/wcwidth/wcwidth.h
index 38c17ac..bb98ab0 100644
--- a/external/wcwidth/wcwidth.h
+++ b/external/wcwidth/wcwidth.h
@@ -3,10 +3,14 @@
 
 #include <stdlib.h>
 
-__BEGIN_DECLS
+#ifdef __cplusplus
+extern "C" {
+#endif
 
 int wcwidth(wchar_t ucs);
 
-__END_DECLS
+#ifdef __cplusplus
+}
+#endif
 
 #endif

fixes the issue, see https://wiki.musl-libc.org/faq.html

None also a valid CMake BUILD_TYPE

This BUILD_TYPE is normally used in distro packaging so the packager can ensure libtsm was built with their compile options. It's also the default value of CMAKE_BUILD_TYPE.

See also https://wiki.archlinux.org/title/CMake_package_guidelines#CMake_can_automatically_override_the_default_compiler_optimization_flag

Generate doxygen documentation

Keycode for backspace

Currently, libtsm sends character 010, ASCII backspace, for the backspace key. This matches the VT100 (https://vt100.net/docs/vt100-ug/chapter3.html#T3-4).

However, the Linux console follows the VT220 and sends character 0177 for the backspace key. See https://vt100.net/docs/vt220-rm/chapter3.html#S3.2.1.2 and https://github.com/torvalds/linux/blob/master/drivers/tty/vt/defkeymap.map#L51.

Because of this default, Debian's /bin/login does not users to backspace in the default configuration, leading to a bug reported in kmscon (https://bugs.debian.org/1014316).

Would it be possible to either change the default or at least make it selectable, like in xterm? If the default is changed, then the lines in kmscon's src/pty.c setting VERASE to 010 can also be deleted (https://github.com/Aetf/kmscon/blob/develop/src/pty.c#L343-L344).

CMake warning on configuration

Some packaging systems flag this.

CMake Warning (dev) at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args`
  (XKBCommon_KeySyms) does not match the name of the calling package
  (XKBCommon).  This can lead to problems in calling code that expects
  `find_package` result variables (e.g., `_FOUND`) to follow a certain
  pattern.
Call Stack (most recent call first):
  cmake/Utilities.cmake:189 (find_package_handle_standard_args)
  cmake/modules/FindXKBCommon.cmake:46 (find_package_handle_library_components)
  CMakeLists.txt:57 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

Folder names in releases not in PV form

In Gentoo portage for example the build/package system expects the source to usually be in the form of "Packagename-Version.tar.gz"
Although I could work around with some variables in ebuild script system.
But would it be possible for the releases to have PV form again like the original?

DECRQM resets terminal

When I start vim on macOS 12.3.1 on an M1 Mac in a terminal based on libtsm I get the strange behaviour that the terminal switches to alternate screen but the content of the screen doesn't look like vim but exactly like the content of the main screen before starting vim. Only difference is that the cursor is in the top left. Only when I enter the usual vim commands parts of the status line appear and it becomes clear that vim is actually running. It is just that the terminal went back to operating on the main screen.

That problem doesn't happen on my Intel Mac with macOS 10.15 and neither does it happen on Linux.

Further investigation showed that at after sending the sequences for its usual startup screen vim sends the sequence \u001B[?12$p. (I have a full record of all the sequences sent by vim leading to the problem but it is a bit lengthy so I omit it here)

When I fed libtsm with the data I captured from vim and used a delay to make it happen in slow motion I could clearly see that vim actually appears on screen at first and it is only with the last line of input that the screen is messed up.

The sequence in question is handled in tsm-vte.c at this location:

1775 } else if (vte->csi_flags & CSI_CASH) {
1776 /* DECRQM: Request DEC Private Mode /
1777 / If CSI_WHAT is set, then enable,
1778 * otherwise disable */
1779 csi_soft_reset(vte);
1780 } else {

If I comment out the soft reset in line 1779 the problem is gone and vim appears on screen in all its glory.

AFAIK this DECRQM is used by the client to request some information. Therefore doing a soft reset seems like a bad way of handling it even if it is not implemented, yet.

PS: When I feed libtsm on other platforms with this sequence the screen is messed up in the same way. It is just that vim on other platforms doesn't send this sequence in the first place (no idea why it does it on the M1 Mac).

pkg-config file is broken when CMAKE_INSTALL_{INCLUDE,LIB}DIR is absolute

As per title: etc/libtsm.pc.in has

prefix=@CMAKE_INSTALL_PREFIX@
exec_prefix=${prefix}
libdir=${exec_prefix}/@CMAKE_INSTALL_LIBDIR@
includedir=${prefix}/@CMAKE_INSTALL_INCLUDEDIR@

and so can’t handle absolute paths in CMAKE_INSTALL_{INCLUDE,LIB}DIR. This leads to broken .pc files on NixOS in particular.

See “Concatenating paths when building pkg-config files” for a thorough discussion of the problem and a suggested fix, or KDE’s extra-cmake-modules for a simpler approach.

Setting custom color palettes.

Hello, first off thank you for a maintained fork of libtsm. I am trying to get a gruvbox-like theme working, and I'm having trouble figuring out how it works. After failing to properly install the dependency from the defunct libtsm, I found this fork. In the readme, you mention support for custom palettes via an api. Am i correct to assume that the custom palette would have to be defined by hand in the code itself(tsm-vte.c)? And if so, how would I go about doing so once the lib is installed on my system. Or am I wrong and it can be define in the (kmscon.conf) file? I am fairly new to c, so my apologies in advance if I botched up this question already. Thanks in advance!

Doesn't build with recent harfbuzz

There is some pkg-config trickery with modern pango+harfbuzz.

Basically, I needed to add -I/usr/include/harfbuzz to the build command line to build gtktsm , even though the distribution does some clever tricks with pkg-config.

can't generate Makefile

Hi, thanks for maintaining this!

I cannot compile:

$ cd ~/libtsm
$ mkdir build
$ cd build
$ cmake ..
CMake Error at CMakeLists.txt:19 (message):
  Usage: mkdir build; cmake ..


-- Configuring incomplete, errors occurred!
See also "~/libtsm/CMakeFiles/CMakeOutput.log".

I am not familiar with CMake, looking into the log file just confused me.

Any ideas?

Proposal: rename to libtsm2 or similar

Reasoning: many distros already have a libtsm package. For instance, in AUR, this makes it impossible for me to package anything relying on this heavily improved libtsm without vendoring it.

Making this libtsm2 or something like that would make room for custom packages in COPR and AUR. Thoughts?