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