diff options
Diffstat (limited to 'content/2023-01-26-trying-to-build-a-new-kind-of-terminal-emulator.md')
| -rw-r--r-- | content/2023-01-26-trying-to-build-a-new-kind-of-terminal-emulator.md | 253 |
1 files changed, 253 insertions, 0 deletions
diff --git a/content/2023-01-26-trying-to-build-a-new-kind-of-terminal-emulator.md b/content/2023-01-26-trying-to-build-a-new-kind-of-terminal-emulator.md new file mode 100644 index 0000000..27e227a --- /dev/null +++ b/content/2023-01-26-trying-to-build-a-new-kind-of-terminal-emulator.md | |||
| @@ -0,0 +1,253 @@ | |||
| 1 | --- | ||
| 2 | title: Trying to build a New kind of terminal emulator for the modern age | ||
| 3 | url: trying-to-build-a-new-kind-of-terminal-emulator.html | ||
| 4 | date: 2023-01-26T12:00:00+02:00 | ||
| 5 | type: post | ||
| 6 | draft: false | ||
| 7 | --- | ||
| 8 | |||
| 9 | Over the past few weeks, I have been really thinking about terminal emulators, | ||
| 10 | how we interact with computers, the separation of text-based programs and GUI | ||
| 11 | ones. To be perfectly honest, I got pissed off one evening when I was cleaning | ||
| 12 | up files on my computer. Normally, I go into console and do `ncdu` and check | ||
| 13 | where the junk is. Then I start deleting stuff. Without any discrimination, | ||
| 14 | usually. But when it comes to screenshots, I have learned that it's good to keep | ||
| 15 | them somewhere near if I need to refer to something that I was doing. I am an | ||
| 16 | avid screenshot taker. So at that point I checked Pictures folder and also did a | ||
| 17 | basic search `find . -type f -name "*.jpg"` for all the JPEG files in my home | ||
| 18 | directory and immediately got pissed off. Why can’t I see thumbnails in my | ||
| 19 | terminal? I know why, but why in the year of 2022 this is still a problem. I am | ||
| 20 | used to traversing my disk via terminal. I am faster, and I am more comfortable | ||
| 21 | this way. But when it comes to visualization, I then need to revert to GUI | ||
| 22 | applications and again find the same file to see it. I know that programs like | ||
| 23 | `feh` and `sxiv` are available, but I would just like to see the preview. Like | ||
| 24 | [Jupyter notebook](https://jupyter.org/) or something similar. Just having it | ||
| 25 | inline. Part of a result. | ||
| 26 | |||
| 27 | It also didn’t help that I was spending some time with the [Plan | ||
| 28 | 9](https://plan9.io/plan9/) Operating system. More specifically | ||
| 29 | [9FRONT](http://9front.org/). The way that [ACME editor](http://acme.cat-v.org/) | ||
| 30 | handles text editing is just wonderful. Different and fresh somehow, even though | ||
| 31 | it’s super old. | ||
| 32 | |||
| 33 | So, I went on a lookout for an interesting way of visualizing results of some | ||
| 34 | query. I found these applications to be outstanding examples of how not to be a | ||
| 35 | captive of a predetermined way of doing things. | ||
| 36 | |||
| 37 | - [Wolfram Mathematica](https://www.wolfram.com/mathematica/) | ||
| 38 | - [Jupyter notebooks](https://jupyter.org/) | ||
| 39 | - [Plan 9 / 9FRONT](http://www.9front.org) | ||
| 40 | - [Temple OS](https://templeos.org/) | ||
| 41 | - [Emacs](https://www.gnu.org/software/emacs/) | ||
| 42 | |||
| 43 | My idea is not as out there as ACME is, but it is a spin on the terminal | ||
| 44 | emulators. I like the modes that Vi/Vim provides you with. I like the way the | ||
| 45 | Emacs does its own `M-x` `M-c`. Furthermore, I really like how Mathematica and | ||
| 46 | Jupyter present the data in a free flowing form. And I love how Temple OS is | ||
| 47 | basically a C interpreter on some level. | ||
| 48 | |||
| 49 | > **Note:** This is part 1 of the journey. Nowhere finished yet. I am just | ||
| 50 | > tinkering with this at the moment. This whole thing can easily spectacularly | ||
| 51 | > fail. | ||
| 52 | |||
| 53 | So I started. I knew that I wanted to have the couple of modes, but I didn’t | ||
| 54 | like the repetition of keystrokes, so the only option was to have some sort of | ||
| 55 | toggle and indicate to the user that they are in a special mode. Like Vi does | ||
| 56 | for Normal and Visual mode. | ||
| 57 | |||
| 58 | These modes would for the first version be: | ||
| 59 | |||
| 60 | - *Preview mode* (toggle with Ctrl + P) | ||
| 61 | - When this mode would be enabled, the `ls` command would try to find images | ||
| 62 | from the results and display thumbnails from them in the terminal itself. | ||
| 63 | No ASCII art. Proper images. In a grid! | ||
| 64 | - *Detach mode* (toggle with Ctrl + D) | ||
| 65 | - When this mode would be enabled, every command would open a new window | ||
| 66 | and execute that command in it. This would be useful for starting `htop` | ||
| 67 | in a separate window. | ||
| 68 | |||
| 69 | The reason for having these modes togglable is to not ask for previews every | ||
| 70 | time. You enable a mode and until you disable it, it behaves that way. Purely | ||
| 71 | out of ergonomic reasons. | ||
| 72 | |||
| 73 | I would like to treat every terminal I open as a session mentally. When I start | ||
| 74 | using the terminal, I start digging deeper into the issue I am trying to | ||
| 75 | resolve. And while I am doing this, I would like to open detached windows | ||
| 76 | etc. A lot of these things can be done easily with something like | ||
| 77 | [i3](https://i3wm.org/), but also that pull you out of the context of what you | ||
| 78 | were doing. I would like to orchestrate everything from one single point. | ||
| 79 | |||
| 80 | In planning for this project, I knew that I would need to use a language like C | ||
| 81 | and a library such as [SDL2](https://www.libsdl.org/) in order to achieve the | ||
| 82 | desired results. I had considered other options, but ultimately determined that | ||
| 83 | [SDL2](https://www.libsdl.org/) was the best fit based on its capabilities and | ||
| 84 | reputation in the programming community. | ||
| 85 | |||
| 86 | At first, I thought the idea of a hardware accelerated terminal was a bit of a | ||
| 87 | joke. It seemed like such a niche and unnecessary feature, especially given the | ||
| 88 | fact that terminal emulators have been around for decades and have always relied | ||
| 89 | on software rendering. But to be fair, [Alacritty](https://alacritty.org/) is | ||
| 90 | doing the same thing. Well, they are doing a remarkable job at it. | ||
| 91 | |||
| 92 | So, I embarked on a journey. Everything has to start somewhere. For me, it | ||
| 93 | started with creating a window! It has to start somewhere. 🙂 | ||
| 94 | |||
| 95 | ```c | ||
| 96 | // Oh, Hi Mark! | ||
| 97 | // Create the window, obviously. | ||
| 98 | SDL_Window *window = SDL_CreateWindow( | ||
| 99 | WINDOW_TITLE, SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, | ||
| 100 | WINDOW_WIDTH, WINDOW_HEIGHT, | ||
| 101 | SDL_WINDOW_RESIZABLE | SDL_WINDOW_OPENGL | SDL_WINDOW_SHOWN); | ||
| 102 | ``` | ||
| 103 | |||
| 104 | I continued like this to get some text displayed on the screen. | ||
| 105 | |||
| 106 | I noted that | ||
| 107 | [`TTF_RenderText_Solid`](https://wiki.libsdl.org/SDL_ttf/TTF_RenderText_Solid) | ||
| 108 | rendered text really poorly. There were no antialiasing at all. In my wisdom, I | ||
| 109 | never checked the documentation. Well, that was a fail. To uneducated like me: | ||
| 110 | `TTF_RenderText_Solid` renders Latin1 text at fast quality to a new 8-bit | ||
| 111 | surface. So, that's why the texts looked like shit. No wonder. | ||
| 112 | |||
| 113 | Remarks on `TTF_RenderText_Solid`: This function will allocate a new 8-bit, | ||
| 114 | palettized surface. The surface's 0 pixel will be the colorkey, giving a | ||
| 115 | transparent background. The 1 pixel will be set to the text color. | ||
| 116 | |||
| 117 | After I replaced it with | ||
| 118 | [`TTF_RenderText_LCD`](https://wiki.libsdl.org/SDL_ttf/TTF_RenderText_LCD) which | ||
| 119 | renders Latin1 text at LCD subpixel quality to a new ARGB surface, the text | ||
| 120 | started looking good. Really make sure you read the documentation. It’s actually | ||
| 121 | good. As a side note, you can find all the documentation regarding [SDL2 on | ||
| 122 | their Wiki](https://wiki.libsdl.org/). | ||
| 123 | |||
| 124 | After that was done, I started working on displaying other things like `Preview` | ||
| 125 | and `Detach` modes. This wasn’t really that hard. In SDL2 you can check all the | ||
| 126 | available events with `while (SDL_PollEvent(&event) > 0)` and have a bunch of | ||
| 127 | switch statements to determine which key is currently being pressed. More about | ||
| 128 | keys, [SDLKey](https://documentation.help/SDL/sdlkey.html) and mroe about | ||
| 129 | pooling the events on | ||
| 130 | [SDL_PollEvent](https://documentation.help/SDL/sdlpollevent.html). | ||
| 131 | |||
| 132 | ```c | ||
| 133 | while (SDL_PollEvent(&event) > 0) | ||
| 134 | { | ||
| 135 | switch (event.type) | ||
| 136 | { | ||
| 137 | case SDL_QUIT: | ||
| 138 | running = false; | ||
| 139 | break; | ||
| 140 | |||
| 141 | case SDL_TEXTINPUT: | ||
| 142 | if (!meta_key_pressed) | ||
| 143 | { | ||
| 144 | strncat(input_prompt_text, event.text.text, 1); | ||
| 145 | update_input_prompt = true; | ||
| 146 | } | ||
| 147 | break; | ||
| 148 | } | ||
| 149 | } | ||
| 150 | ``` | ||
| 151 | |||
| 152 | After that was somewhat working correctly, I started creating a struct that | ||
| 153 | would hold all the commands and results and I call them Cells. Yes, I stole that | ||
| 154 | naming idea from Jupyter. | ||
| 155 | |||
| 156 | ```c | ||
| 157 | typedef struct | ||
| 158 | { | ||
| 159 | char *command; | ||
| 160 | char *result; | ||
| 161 | SDL_Surface *surface; | ||
| 162 | SDL_Texture *texture; | ||
| 163 | SDL_Rect rect; | ||
| 164 | } Cell; | ||
| 165 | ``` | ||
| 166 | |||
| 167 | I am at a place now where I am starting to implement scrolling. This will for | ||
| 168 | sure be fun to code. Memory management in C is super easy. 😂 | ||
| 169 | |||
| 170 | I have also added a simple [INI file like | ||
| 171 | configuration](https://en.wikipedia.org/wiki/INI_file) support. It is done in an | ||
| 172 | [STB style of | ||
| 173 | header](https://github.com/nothings/stb/blob/master/docs/stb_howto.txt) and maps | ||
| 174 | to specific options supported by the terminal. It is not universal, and the code | ||
| 175 | below demonstrates how I will use it in the future. | ||
| 176 | |||
| 177 | ```c | ||
| 178 | #ifndef CONFIG_H | ||
| 179 | #define CONFIG_H | ||
| 180 | |||
| 181 | /* | ||
| 182 | # This is a comment | ||
| 183 | |||
| 184 | # This is the first configuration option | ||
| 185 | dettach=value11111 | ||
| 186 | |||
| 187 | # This is the second configuration option | ||
| 188 | preview=value22222 | ||
| 189 | |||
| 190 | # This is the third configuration option | ||
| 191 | debug=value33333 | ||
| 192 | */ | ||
| 193 | |||
| 194 | // Define a struct to hold the configuration options | ||
| 195 | typedef struct | ||
| 196 | { | ||
| 197 | char dettach[256]; | ||
| 198 | char preview[256]; | ||
| 199 | char debug[256]; | ||
| 200 | } Config; | ||
| 201 | |||
| 202 | // Read the configuration file and return the options as a struct | ||
| 203 | extern Config read_config_file(const char *filename) | ||
| 204 | { | ||
| 205 | // Create a struct to hold the configuration options | ||
| 206 | Config config = {0}; | ||
| 207 | |||
| 208 | // Open the configuration file | ||
| 209 | FILE *file = fopen(filename, "r"); | ||
| 210 | |||
| 211 | // Read each line from the file | ||
| 212 | char line[256]; | ||
| 213 | while (fgets(line, sizeof(line), file)) | ||
| 214 | { | ||
| 215 | // Check if this line is a comment or empty | ||
| 216 | if (line[0] == '#' || line[0] == '\n') | ||
| 217 | continue; | ||
| 218 | |||
| 219 | // Parse the line to get the option and value | ||
| 220 | char option[128], value[128]; | ||
| 221 | if (sscanf(line, "%[^=]=%s", option, value) != 2) | ||
| 222 | continue; | ||
| 223 | |||
| 224 | // Set the value of the appropriate option in the config struct | ||
| 225 | if (strcmp(option, "dettach") == 0) | ||
| 226 | { | ||
| 227 | strncpy(config.option1, value, sizeof(config.option1)); | ||
| 228 | } | ||
| 229 | else if (strcmp(option, "preview") == 0) | ||
| 230 | { | ||
| 231 | strncpy(config.option2, value, sizeof(config.option2)); | ||
| 232 | } | ||
| 233 | else if (strcmp(option, "debug") == 0) | ||
| 234 | { | ||
| 235 | strncpy(config.option3, value, sizeof(config.option3)); | ||
| 236 | } | ||
| 237 | } | ||
| 238 | |||
| 239 | // Close the configuration file | ||
| 240 | fclose(file); | ||
| 241 | |||
| 242 | // Return the configuration options | ||
| 243 | return config; | ||
| 244 | } | ||
| 245 | |||
| 246 | #endif | ||
| 247 | ``` | ||
| 248 | |||
| 249 | This is as far as I managed to get for now. I have a daily job and this | ||
| 250 | prohibits me to work on these things full time. But I should probably get back | ||
| 251 | and finish this. At least have a simple version working out, so I can start | ||
| 252 | testing it on my machines. Fingers crossed. 🕵️♂️ | ||
| 253 | |||
