jupyter-xeus/cpp-terminal

C++ library for writing multiplatform terminal applications

CPP-Terminal is a small and dependency-free C++ library for writing platform independent terminal-based applications. It follows the "Zero-overhead principle" and limits externally included files to the C++ STL. Being cross-platform we are currently supporting Windows, Linux and MacOS and are providing an unified API across all platforms. Our main features are consisting of Colors, Keyboard input, terminal resize handling, as well as other common terminal functionality. It's also possible to open a managed terminal from a windows GUI application.

Hello World example

To write a simple Hello World program, all you need to do is:

#include "cpp-terminal/terminal.hpp"
#include <iostream>

int main()
{
  std::cout << "Just including terminal.hpp activate \033[31mcolor\033[0m !" << std::endl;
}

or

#include "cpp-terminal/terminal.hpp"
#include "cpp-terminal/color.hpp"
#include <iostream>

int main()
{
  std::cout << Term::color_fg(Term::Color::Name::Red)<<"Hello world !"<<color_fg(Term::Color::Name::Default)<< std::endl;
}

On windows you can simply create or attach a console through a GUI application by doing:

#include "cpp-terminal/terminal.hpp"
#include "cpp-terminal/color.hpp"
#include <iostream>
#include <windows.h>

int __stdcall WinMain(HINSTANCE hinst, HINSTANCE hprev, LPSTR cmdline, int show)
{
  std::cout << Term::color_fg(Term::Color::Name::Red)<<"Hello world !"<<color_fg(Term::Color::Name::Default)<< std::endl;
  return 0;
}

Until 2021, CPP-Terminal used to be a single header library. Now, CPP-Terminal consists out of multiple small and usage oriented headers:

• cpp-terminal/input.hpp: functions for gathering input
• cpp-terminal/prompt.hpp: some variations of different prompts
• cpp-terminal/window.hpp: a fully managed terminal window for terminal user interfaces (TUI)
• cpp-terminal/version.hpp: macros with cpp-terminal's version number

CPP-Terminal tries to be a small and simple replacement for ncurses. This approach keeps the code small and maintainable, but also easy to extend it's functionality. We limit ourselves to a subset of features that work on all supported platforms without needing to worry about style differences or other changes. Any application written with CPP-Terminal will work everywhere out of the box natively, without emulation or extra work. The small codebase makes CPP-Terminal easy to debug and extend, as well as understanding what happens behind the scenes in the library's core.

Examples

We have created serval examples to show possible use cases of CPP-Terminal and to get you started more quickly. Every example works natively on all platforms in the exact same way:

• colors.cpp: basic color, style and unicode demo
• kilo.cpp: the kilo text editor ported to C++ and CPP-Terminal instead of using Linux specific API
• menu.cpp: An interactive menu using only the contents of cpp-terminal/base.hpp
• menu_window.cpp: An interactive menu using the fully managed windowing system from cpp-terminal/window.hpp
• keys.cpp: Interactively shows the keys pressed

Supported platforms

Platform	Supported versions	Arch	Compiler	C++ standard
Windows	10 and higher*	x86, x86_64	MSVC 2019, MSVC 2022, clang11, clang12, clang13, clang14, clang15, clang-cl	11,14,17,20
(Windows) MSYS2	All supported	x86, x86_64	ucrt , clang, mingw	11,14,17,20
MacOS	11		xcode11.7 xcode12.4 xcode12.5.1 xcode13 gcc10 gcc11 gcc12	11,14,17,20
MacOS	12		xcode13.1 xcode13.2 xcode13.3 xcode13.4	11,14,17,20
Linux	All supported	x86_64	4.7<=GCC<= 12 3.5<=Clang<=15 intel-oneapi	11,14,17,20
Linux (dockcross)	All supported	arm64 armv5 armv5-musl armv5-uclibc armv6 armv7a, mips, mipsel-lts, s390x, ppc64le, xtensa-uclibc, x86, x64, x64-clang, x64-tinycc	4.7<=GCC<= 12 3.5<=Clang<=15	11,14,17,20

Windows versions prior Windows 10 are missing the Win32 API functionality for entering the "raw mode" and therefore won't work. They are also lacking ANSI support. See #173 for adding support to prior windows versions for MSVC / Win32.

How to use

Adding CPP-Terminal to your own project is really easy. We have collected various ways with easy how-to's in our documentation.

Documentation

🌍 Online 📖 PDF

Contributing

Contributing to CPP-Terminal is highly appreciated and can be done in more ways than code. Extending it's functionality, reporting or fixing bugs and extending the documentations are just a few of them.

License

CPP-Terminal is licensed under the terms of the MIT License by Ondřej Čertík.

Projects using cpp-terminal

• Lime

Similar Projects

Colors

Libraries to handle color output.

C++:

• rang

Drawing

JavaScript:

• node-drawille

Prompt

Libraries to handle a prompt in terminals.

C and C++:

• readline
• libedit
• linenoise
• replxx

Python:

• python-prompt-toolkit

General TUI libraries

C and C++:

• curses and ncurses
• Newt
• termbox
• FTXUI
• ImTui

Python:

• urwid
• python-prompt-toolkit
• npyscreen
• curtsies

Go:

• gocui
• clui
• tview
• termbox-go
• termui
• tcell

Rust:

• tui-rs

JavaScript:

• blessed and blessed-contrib

cpp-terminal's Issues

Fix alt heys

As we have discussed in #104 we have to fix issues with the alt keys. The current macro tends to cast values greater than 127 into a char type which results into a runtime error because a char can only hold values from 0 to 127.

checking of clang-format for pull-requests

I thought about maybe creating a github action which just checks, if the commit is formated by clang-format to prevent pushing of unformated code into the master master branch. The same could be done with clang-tidy as soon as it's set up as well.

Document all terminals that we tested

And specify any caveats if any for each.

Add a `Prompt [y/n]`

This would wait for y/n answer.

@wolfv knows the exact requirements.

Add a make install target to install into a prefix

... or use CMake?
That would make it easy to have terminal on conda-forge, and we could use it right away in mamba.

I just tested it and it looks very impressive and also very much like what we need so I am happy to help out here.

Improve the readme

I was thinking about making the readme a bit prettier by adding CI checks, version (if added) and/or thing like code quality badges to the readme. Maybe some smaller visual changes too. I'll make a sample of what I think of soon.

Support 24bit colors

Currently cpp-terminal only supports 4bit colors. We should extend it to also support 24 bit colors:

https://en.wikipedia.org/wiki/ANSI_escape_code#24-bit

We have to add a new function color_24bit (similar to the current function color which is only 4 bit) and use the ESC[ 38;2;⟨r⟩;⟨g⟩;⟨b⟩ m sequence to set it.

Then we need to extend the Window class, currently the color is only represented by the 3bit color vector<fg>. Instead we have to change it to vector<Color>, where the Color struct is something like this:

struct Color {
    enum { bit24, bit3, bit4 } tag;
    union {
        struct {
            char R, G, B;
        };   
        fg color_fg;
        fgB color_fgB;
    };  
};   

and then the set_fg method would become:

void set_fg(size_t x, size_t y, fg c) {
    m_fg[(y-1)*w+(x-1)].tag = bit3;    
    m_fg[(y-1)*w+(x-1)].color_fg = c;  
}

void set_fg_24bit(size_t x, size_t y, char R, char G, char B) {
    m_fg[(y-1)*w+(x-1)].tag = bit24;
    m_fg[(y-1)*w+(x-1)].R = R;      
    m_fg[(y-1)*w+(x-1)].G = G;
    m_fg[(y-1)*w+(x-1)].B = B;
}

Also the render method would need to be updated.

Move to an organization

We have brainstormed a few ideas, but I think we haven't figured out which organization (or a new one) should we moved this under.

/cc @wolfv, @martinRenou

small imprevements

Term::Terminal should have an option to call std::cout << Term::cursor_off(); in it's constructor and should re-enable the cursor in the destructor.

Also a small fix for terminals like the linux TTY:
Terminal::savescreen() should also do std::cout << Term::clear_screen_buffer() << std::flush;after saving the screen to avoid left over characters on terminals that do no support the save and restore ANSI codes. Also the restore function should do the same and move the cusrsor to 1,1 before restoring the screen to avoid lefover characters and black space (otherwise the prompt would be on the line where the cursor was).

add CodeQL scanning

CodeQL is a security scanning tool by github, free with github actions. It's scanning code for security riscs and some bad practices.

https://securitylab.github.com/tools/codeql

Probably not a measurement for "This code is secure", but a good thing to avoid misstakes that are already documented.

removed the get_term_size_slow() function

Remove the get_term_size_slow() function, because it's already improved and will probably not needed anyway.

move testing into tests folder

I would like to move all files used for testing into a tests/ folder to make the repository more cleaned up.

fix ALT+N

Even after the fix of the alt and ctrl keys ALT+N remains broken. I'm not sure yet what's exactly the problem, but it's inside of the utf8_to_utf32() functions because it's throwing a runtime_error when you press it. The console output is:

[mcwertgaming@archlinux examples]$ /home/mcwertgaming/git/cpp-terminal/build/examples/prompt
Interactive prompt.
  * Use Ctrl-D to exit.
  * Use Enter to submit.
  * Features:
    - Editing (Keys: Left, Right, Home, End, Backspace)
    - History (Keys: Up, Down)
    - Multi-line editing (use Alt-Enter to add a new line)
> Runtime error: Expected more bytes in UTF8 encoded string                                                                                                                                                                                                                        1,1   ]
[mcwertgaming@archlinux examples]$

merge window and window_24bit together

We need to merge the Term::Window and Term::WIndow_24bit classes some day to avoid having the same code twice (and fix things twice too). The first idea of:

struct Color {
    enum { bit24, bit3, bit4 } tag;
    union {
        struct {
            char R, G, B;
        };   
        fg color_fg;
        fgB color_fgB;
    };  
};   

Didn't worked, because of the vectors and forbidden anonymous structures and unions. A different approach is required here.

Recommended version

Hello there, I would like to use cpp-terminal in Mamba. Specifically we'd like to use it for a yes/no prompt with Ctrl+C support. What's the recommended version to use right now? Would you recommend using latest master, or v0.1, or would you consider publishing a more recent stable release?

Clarify what goes and what does not go into terminal.h

A good rule seems to be:

• color output
• keyboard input
• querying terminal properties such as whether we are running in a terminal, terminal dimensions, etc.
• Screen class, that works like ncurses window
• Unicode support (input, output, Screen)
• Multiplatform support

Improvements, redesigns, etc. would go into terminal.h. It seems it's possible to keep it under, say, 2000 lines of code and have all this functionality in. So terminal.h would act as a multiplatform ncurses replacement.

Everything else (such as widgets) would go into other header files (or a separate library).

This scope of terminal.h should be documented in the README.

restructure the header files

Basically moving cpp-terminal's functions between the header files so the provided set of functions makes actually sense. This will also include cutting the BaseTerminal and Terminal classes so they actually make sense.

document taken keys

I think it would be good to provide warnings for problematic keys. That would include:

• CTRL+C (stops the program, can be deactivated)
• CTRL+Z (the same as CTRL+C but with a messasage)
• CTRL+J (open/close vscode terminal)
• CTRL+K (vscode commands)
• CTRL+F (vscode find)
• CTRL+M (vscode tab focus toggle)
• CTRL+E (vscode open file)
• probably some more

Is there maybe any way to check for throw errors on compile time based on function input? Or something like that?

Prompt example very CPU intensive

The prompt example uses 100% of one of my CPU core, and the fan starts as soon as I execute the binary.

Maybe read_key should sleep a bit between reads? Sleeping 10ms might be good enough for easing the CPU while still having a good user experience when typing?

    int read_key() const
    {
        int key;
        using namespace std::chrono_literals;
        std::this_thread::sleep_for(10ms);

        while ((key = read_key0()) == 0) { std::this_thread::sleep_for(10ms); }
        return key;
    }

Resize

There is a problem in windows.
in the menu example.
when you resize the height the menu doubles up because it not clearing or over writing the full console.
I think in windows you need to write to the consoles buffer directly.

add support for Dear ImGUI

As discussed in #119 it would be a good feature to make it possible to use Dear ImGUI inside of cpp-terminal.

Unit testing

The doctest.h file in the root of the repository claims to be gerated by cmake - but that's a lie. I would sugest to let it really be generated by cmake, or at least get updated every now and then. We are using 2.3.4, newest version is 2.4.5. I would remove the file and setup doctest as cmake sub-project.

Another solution would be moving to gtest (the unit testing framework, I usually use). It's basially the same but if I got it right, it can even test colors and stuff like that. I'll definietely test it a bit in terms of benefits for cpp-terminal and I understand, if you don't want to move yet. Do you know that testing framework at all?

Release tags

I have created the release tag V1.0.0. Do you agree on doing it like that? or would you prefer to do it different? And do you want to make a new release on every merged pull-request? Or rather like once a week or something like that?

Unify Window and Window_24bit

We have to unify the color type as follows:

diff --git a/cpp-terminal/terminal.cpp b/cpp-terminal/terminal.cpp
index 69a303f..ff076b8 100644
--- a/cpp-terminal/terminal.cpp
+++ b/cpp-terminal/terminal.cpp
@@ -624,6 +624,13 @@ void Term::Window_24bit::clear() {
 }
 
 bool Term::Window_24bit::rgb_equal(rgb& rgb_one, rgb rgb_two) {
+    if (rgb_two.color_type == rgb::type_basic) {
+        std::cout << rgb_two.color_type_union.basic << std::endl;
+    } else {
+        std::cout << rgb_two.color_type_union.rgb.r << std::endl;
+        std::cout << rgb_two.color_type_union.rgb.g << std::endl;
+        std::cout << rgb_two.color_type_union.rgb.b << std::endl;
+    }
     return rgb_one.r == rgb_two.r && rgb_one.b == rgb_two.b &&
            rgb_one.g == rgb_two.g;
 }
diff --git a/cpp-terminal/terminal.h b/cpp-terminal/terminal.h
index a7b384c..c0e4999 100644
--- a/cpp-terminal/terminal.h
+++ b/cpp-terminal/terminal.h
@@ -196,6 +196,33 @@ class Window_24bit {
     std::vector<char32_t> chars;  // the characters in row first order
     struct rgb {
         unsigned int r, g, b;
+        enum ColorType {
+            type_rgb, type_basic
+        } color_type;
+        union ColorTypeUnion {
+            struct {
+                unsigned int r, g, b;
+            } rgb;
+            enum BasicColors {
+                black = 30,
+                red = 31,
+                green = 32,
+                yellow = 33,
+                blue = 34,
+                magenta = 35,
+                cyan = 36,
+                white = 37,
+                reset = 39,
+                gray = 90,
+                bright_red = 91,
+                bright_green = 92,
+                bright_yellow = 93,
+                bright_blue = 94,
+                bright_magenta = 95,
+                bright_cyan = 96,
+                bright_white = 97
+            } basic;
+        } color_type_union;
     };
     std::vector<rgb> m_fg;
     std::vector<rgb> m_bg;

This provides an example how to declare it and how to access it.

Split the prompt into its own header file

Currently the single line prompt is in the terminal.h header file. We should split it into its own header file and possible a namespace.

move all functions into Term namespace

I thought, if we move the write function to Term::write() (disqussed in #81), shouldn't we just move all function there including the console_is_a_tty outside of the class into the namespace? I think that would look better. You can use using namespace Term to just use the namesapce and skip the Term:: part.

Visual studio code terminal issue

Hey,
i encountered some problems with cpp-terminal while working inside of visual studio code. The window class causes wrong colors on wrong parts on the screen and visual studio crashes sometimes while debugging. I will look into the cause (and will try to fix that) later on.

Here is what I mean:

The crash happens randomly, i'm not sure yet on how to replicate it.

The color chart in ./colors seems incorrect on macOS

On macOS it looks like this:

de-complicate the library

At investigating a better solution to the sscanf problem I notices that the code is really complicated (or at least to me). I would be happy to "de-complicate" the code by changing workarounds around some things to shorter and more simple solutions (for example you created two while loops inside get_cursor_position() with creating the i var above and are using it inside both while loops and outside. I would like to make both while loops into for loops and move all parts which need the i car inside that loop. The contents of the same functions are really complicated too, like you created inline functions like write(), but it's contents was just std::cout << s << std::flush; I thought you would just write something elsewhere but not into stdout. So why not just doing that immediately where its needed? It would help others to understand your code faster). I have to add that I'm new to ANSI and this library is the first I'm contributing to and i respect if you don't like some things in upstream.

Changes i would like to make:

• simply-size some functions and loops
• move the ANSI code into definitions (macros) instead of inline functions (better readability and less code)
• split class definition and function definitions (move the sources of all functions outside the class definition)
• that would be nice because the system dependent stuff with all the #ifdef makes it really hard to tell what functions are provided
• move all static member functions of base_terminal class outside into the Term namespace (if it isn't already, my IDE is a bit confused with all the system dependent code)
• (remove the slow functions, as I'm not sure if anyone need them but it's optional)
• try to remove the binary bit wise operators as they are not recommended in C++ (and clang-tidy note, that it should be avoided)
• adding default labels to switch statement to throw a runtime_error, if an illegal or not caught value somehow manages to happen
• trying on making get_term_size() static, as only windows needs members, but maybe you could just make a workaround (that would enable the usage without needing the object of it's class)
• maybe some more things

I just wanted to ask, if these changes are welcomed inside this project. As I will use this library for some small games I write to practice programming, I'm willing to improve it with my own ideas.

Greetings!
Damon Leven

Port multiline REPL from LFortran to cpp-terminal

Thanks to Dominic Poerio we now have a working multi-line REPL in LFortran:

https://gitlab.com/lfortran/lfortran/-/blob/44bad104711796fa0b4743460ea832c0ee04682a/src/bin/lfortran.cpp#L226
https://gitlab.com/lfortran/lfortran/-/blob/44bad104711796fa0b4743460ea832c0ee04682a/src/bin/tpl/cpp-terminal/prompt0.h

We should port it to cpp-terminal so that other projects can also use it.

use sourcefile instead of 'just' headers

Hello,

i want to ask, if I can split the header files of this library into header and source files. Yes, I am aware of the desciption advertising this library as a "header only library", but I see many disadvantages here.

First of all we face many bad practices:

• function bodies inside classes
• internal enums and macros are exposed / included
• includes get included into all projects (that mean users can't keep on track, wich libraries are inlcuded with the two headers(with include themselves as well) so all includes are also available inside the main project)
• There are probably some more...

And I want to note, that this library is quiet small and consist of two headers. I would like to move the source parts into a source file and keep the class and function definitions inside of the header file (we can even move both header together, something you were / are already planing to do, if I saw that right). As most people (hopefully) use cpp-terminal as cmake dependency, there wouldn't be anything different for them at all, if they just copy the files they would have to copy two or 3/4 files and add the source file/s to their compile target - I wouldn't call that much more complicated.

Critizism is appreceated, it's an Idea - I hope this is not against the goal of this library!

Best regards
Damon

Use clang-format

And enforce it on the CI.

CI: Enable all warnings on all compilers and turn them into errors

That way the CI will fail if any compiler issues a warning, so that we can catch any regressions.

Functions for determining terminal support

I think it would be a great thing to have functions to determine things like color support (4bit / 24bit) and maybe even some more information on what the current terminal supports. That would also make it possible to include fall back functions in window24 for example (we could fall back to 4bit colors, if 24bit is not supported). As Ncurses and such libraries are already implementing that feature I think this won't that of a big deal. I have looked it up quickly, but there are no ANSI code for that, also it would require a system dependent solution (on linux probably even terminal dependent). Windows has some functions inside of windows.h to do that, linux has the TERM variable. The problem with the term variable though is that Terminals like xterm and the visual studio integrated terminal set it to xterm-256color wich means that it supports 256 colors (8bit colors) but doesn't tells if it supports true color (24bit) for example. The actuall problem here is that Kitty (my primary terminal) sets it to "xterm-kitty" which means that if we just check that variable to be equal to "xterm-256color" we wouldn't cover all terminals.

But I think this would be a great thing, if we are done with #73.

tty status function location

We already dicussed in #68 that we could move is_stdin_a_tty() and is_stdout_a_tty() outside of the class. As it is already a static member, no object is required. It's just a question of preference. What do you think? Rather leave everything as it is, or rather move both functions out of the class into the namespace?

Create a wiki

Until now, cpp-terminal is documented in examples and small snippets in the readme only. A wiki would give new users better a better understanding on what cpp-terminal is and how you can use it the best.

Help is really apreceated!

Implement more efficient `render` algorithm

Currently the render method always prints the whole Window from scratch.

Instead, we should add an optional argument Window &old_window which would represent the current state of the screen and render would do an efficient diff against it and only update things that changed (characters and colors).

This should be done after #69 is fixed, as that issue will extend how colors are represented in Window.

Consider making Terminal a global singleton object

• This allows construction on first use and would eliminate the need to create Term::Terminal term in the main program.
• Downside: I'm not 100% certain this can be implemented in a header only package. I think the instance pointer might need to be initialized in a cpp file. I'll need to investigate further.

Add versioning

Adding versioning to cpp-terminal would allow developers depending on cpp-terminal to depend on a specific version of cpp-terminal and don't have to fear their applications to be broken by breaking changes for example.
This would include using the VERSION variable in cmake and providing a dedicated header cmake will generate and the creation of git tags (like on every pull-request merge).

cpp-terminal road map

I have thought of some things, I would like to to do with cpp-terminal to make it better for it's purpose - providing a way to write cross-platform terminal applications. I thought of doing those steps in the particular order:

1. Split cpp-terminal into smaller use case defined parts (#67)

• cpp-terminal/base.hpp which provides the raw functions to handle console input (basically the color functions and such)
• cpp-terminal/window.hpp which provides a manages "window", basically the window class
• cpp-terminal/input.hpp which provides the input functions
• cpp-terminal/prompt.hpp which provides the prompt and things like (#72)
• cpp-terminal/tools.hpp wich provides all function which are just meant for being used inside of the library
• restructure the header files (#117)

2. Improve testing and similar

• #148
• Improve stand-alone test (if needed) (#109)
• add github-action for checking if clang-format was applied (#92)
  -> add github actions for automatically applying clang-format (like with /bot apply-clang-format as issue comment)
• add testing for the interactive prompt (#59)
• enable more warnings and make them errors (#33)
• #149
• use the doctest.h to a cmake or git sub module (#88)
• #150
• #151

3. Improve the libraries core

• merge window and window_24bit together (#96)
• change the stand-alone color functions to always use the best, but supported color range
  -> fixes #108
• change the window class to always chose the highest (but supported) color range
  -> fixes #107
• add functions to determine ANSI code support by the current terminal (#102)
• make the window class specific functions also available as stand alone
  -> maybe even use those functions inside of the Window class to prevent duplicate code
• fix the visual studio color problem (#95)
• Improve the window class render() algorithm (#71)
• #152
• fix ALT+N (#118)
• #153
• let cpp-terminal handle most things it self #120

4. Finishing up

• create an actual documentation for cpp-terminal (#70)
• document taken keys (#112)
• add more exceptions to help developers on finding mistakes (#98)
• add proper versioning (#90)
• improve the readme (#75)
• Document all tested terminals (#73)
• maybe remove get_term_size_slow() (#115)
• #154

5. Extending the library

• add more options for drawing
• integrate proper resize handling into the window class (#94)
• optimize the Window class for real time applications (games mostly)
• #156
• add syntax highlighting
• #155
• make the prompt more customizable for other developers
• support Dear ImGUI #121

I will make this Issue pinned on the repository and update it when needed to keep track on the things we want to do. Also for other peoples and possible contributors. Help is always appreciated!

Mark more functions inline

So that one does not need to move them to a cpp file.

improve standalone test

As my project broke (again) because the master master branch of cpp-terminal has functions which are not declared as static and included into two source files that get compiled together, I would like to add another source file to the stand-alone test to avoid such mistakes in the future.

Consolidate the two headers

Move terminal_base.h into terminal.h. That way there is just one header and it's easier to distribute.

adding more exeptions

cpp-terminal is currently not checking that much for legal inputs on some functions. For example: Term::Window_24bit scr(0, 0, 10, 10); returns a segmentation fault, because the used vectors of the window class can't have negative places. we should simply throw a std::runtime_error here. That would include:

• Term::Window
• Term::Window_24bit
• (with some functions, like Term::Window::fill_bg)
• Term::color
• Term::color_24bit
  and probably all other functions without enforced types (like enums)

Suggestions, questions, more

• Since you have a function color, does it make sense to also provide a function to remove color from strings?

#include <regex>
...
inline std::string remove_color(std::string const &colored_string) {
  std::regex color_regex("\033[" "[[:digit:]]+[m]");
  return std::regex_replace(colored_string, color_regex, "");
}

• It might be worth moving Taylor Campbell's code to its own header to make it easier to keep the Copyright intact and associated with his code.
• I chose to add inline to most of the functions in terminal.hh to avoid possible multiple definition (e.g. lib1->terminal.h, lib2-> terminal.h, app1-> {lib1, lib2}).
• In terminal_base.h, I had to add #define _WINSOCKAPI_ just before #include <windows.h> to avoid multiple definition collisions with winsock2.h that I use in my code. I don't really understand this, but this work-around seems to do the right thing.
• In terminal.h, I needed to make a few changes to avoid warnings:
  • Fix a warning about incorrect length of strings

-      write("\0338");       // restore current cursor position
+      write("\033" "8"); // restore current cursor position

-    write("\0337");       // save current cursor position
+    write("\033" "7");           // save current cursor position

• I needed to change a lot of int to size_t to avoid build warnings under MSVC (with option /W4). There were also some character types that needed to be more specific (char -> char32_t, etc.). I'll create a patch file or PR for these so you can review them. Example:

-  uint32_t codepoint, state = UTF8_ACCEPT;
+  uint32_t codepoint;
+  uint8_t state = UTF8_ACCEPT;

CI: add tests for an interactive prompt

The way to test it is to add the input into a file, and then redirect stdin from this file. An example would be a string like
"Hello Wold!" and check that we get the correct string. The <LEFT ARROW> and <DELETE> are meant to be the corresponding escape sequences for those keys.

B0 define conflicts on Linux with user code

Due to this define:

https://github.com/bminor/glibc/blob/0b262ca4c64cd9042576ddb9969607c0ea1187d7/bits/termios.h#L288

user code can break. To fix it, we should but

#undef B0

right after including termios.h. The same for all the other constants.

Reported by @KineticTheory.

Clash between two libs

Hello,

I'm using your library for a small project. It works well for what I want to do. However, I have an error because I'm using an other library for reading, writing and modifying json (https://github.com/nlohmann/json). This lib declares two variables UTF8_ACCEPT and UTF8_REJECT that are also declared in your library. Since the json library variables are declared as static constexpr and yours using #define, compilation fail. I manage to fix this issue by declaring the two variables in your lib as static constexpr as follow, at lines 448 and 449 of terminal.h:

static constexpr std::uint8_t UTF8_ACCEPT = 0;
static constexpr std::uint8_t UTF8_REJECT = 0xf;

Since the json library is quite common lib in projects, this minor change can be done to avoid clash between the libs.

Regards.
Guillaume Le Pape

add dotfiles

This is meant to add the usuall dotfiles. I'm thinking of a .gitingore and a .clang-format, but can be extended with .clang-tidy (static analysis), .gitpod (an online version of visual studio code, runs a free IDE on the web with everything included inside the file), GitHub codespaces (GitHub version of gitpod, runs visual studio code remote containers for free on the web). I don't know if all are actually usefull, but I wanted to note that they exist. There are even more, but I would prefer to keep it to the minimum required files.

menu_window_24bit does not seem to work on macOS

Here is how it looks like for me:

It's actually blinking. And when I press an arrow, it disappears.