On Terminals, Emacs, and AI Coding

Not an audio post, just some thoughts on programming hackery, see also my old similar posts On Keyboards and Long Live 16 Color Terminals.

I think we have now entered the "Golden Age" of programming and use of computers in general—all thanks to AI. That's because Programming tasks that once took days can now be finished in a couple of hours. A personal example of this is my experience extending the Emacs editor. This is ages old "universal" editor—its original concept was created in 1976 at the MIT AI Lab, while GNU Emacs program that I use today was created in the mid-80s. However, it is still popular today among programmers and geeks thanks to its infinite possibilities in customizing and embracing new technologies. I use it every day and continue customizing it to my needs.

The customization of Emacs is done by writing some Emacs Lisp code. If your need is simple, like creating some custom action, or fixing some annoying behavior, a small code snippet usually suffices. If your demand is more serious, like enabling code highlighting and completion for some obscure programming language, you need to create a relatively big chunk of code, which in Emacs world is called a "package." If you are lucky, someone has already faced the same problem and written a package to solve it. In that case, the only thing you need to do is to plug this package into your configuration.

If your need is more or less unique for some reason, then you have to write code yourself. It's not super hard, but it's tedious, mainly because you need to study extensive Emacs APIs and consider how to express the solution in terms of list structures manipulation. Also, you need to write code that handles errors, and make sure that your solution works with acceptable speed. In order to accomplish all this, you used to have to comb through Emacs documentation, source code, and if nothing helps, resort to seeking help at online forums—this is what programming used to be. Since I usually needed to deal with this stuff during my work hours, the thought of writing a complex Emacs extension in my spare time sparked no joy.

Enter the Age of AI. Now, if I need to solve some simple Emacs customization task, or fix an annoyance, I can simply ask an LLM, "In Emacs, how do I ... ?", and it comes with a helpful answer and a snippet of Emacs Lisp code which does the thing you have asked about. In this way, I quickly resolved minor Emacs "friction points" that had bugged me for years. One big annoying thing still remained though—adding support for proper displaying of output from semi-interactive build and install scripts and programs in "shell" and "compilation" modes of Emacs. To explain this problem, I first need to give a brief lesson in computer history.

A Brief Course in Unix Terminals (and Editors) Evolution

The interface between humans and computers has evolved constantly since their inception. At first, humans had to program computers—that is, setting them up for solving a particular problem—by patching cables between physical ports, or flipping myriad switches (examples from Wikipedia). And computers were presenting the results of their work using arrays of lights. After the next computer interface evolution step people could enter data into computers using manually perforated cards, and the computer could print the calculation results on long rolls of paper, using motorized versions of typewriters. Both of those kinds of interfaces were not very much interactive, and required a good amount of planning ahead in order to avoid wasting precious compute time.

The interaction aspect had been improved by combining the aforementioned motorized typewriters with a typewriter-like keyboard (see this article about the legendary "Model 33" teletype). Finally, humans could type their commands or code in, and the computer could print the result immediately. You might have noted that this is already very similar to how we are interacting with AI assistants on the Web today, except that teletypes were much noisier.

Crucially, even at this early stage, a distinction between "symbol" and "control" characters was already apparent. When you see a printed page, you only see the letters of alphabet and punctuation—that's symbols. However, for producing this page, the typewriter operator (being that human or a computer) also needed to use some commands in order to drive the typewriter actions like performing a step roll of the paper, or move the printing head forward or back. Each of these actions was coming to the typewriter on the same lines as printable symbols, and is encoded using a control character.

Thus, when a computer sends the result to a typewriter terminal, symbol characters are interleaved with control characters in the same "stream" of data. Same thing for the human—although most of the typewriter keys are for inserting symbols, some keys like "carriage return" and "backspace" are for sending commands. The computer also has a bonus command called "bell" which it had adopted from telegraphy (so it actually predates computers). This command originally rang a physical bell inside the teletype machine. Nowadays, the computer just emits a short beep in order to attract the operator's attention.

Despite being quite basic, this typewriter interface had already opened a way to create interactive text editor programs. The most well known line-oriented text editor is ed. Its interface was designed to be very minimalist and terse, in order to save paper. ed was called "the standard text editor" in Unix OS—and now this is a hacker's joke. In fact, ed is still supplied with most OSes that descend from Linux.

Upon launching ed, you see no prompt; the program simply waits for your commands. The command is typically just one character, plus parameter. If ed does not understand your command, it prints ?, that's it. Since the file you are editing can be lengthy, ed does not reveal its contents—instead, you have to explicitly ask it to show a region of lines, and of course you can not edit them "in place", you need to enter a command for making each edit. Also, since on a typewriter it's not possible to correct typing mistakes in-place—there was no concept of "line editing" using "cursor left / right" commands, you could only use "backspace" and then re-type part of your command, or discard the entire command line and re-type from scratch. Needless to say, editing text files using these basic capabilities required very good memory, skills, and a lot of patience.

Nevertheless, it was the best user interface that programmers had at that time, and in fact the early Unix OS code was written using ed. As Brian Kernigan recalls in "UNIX A History and a Memoir" book, there were three main components that allowed development of Unix for PDP-7 computer on the computer itself: an editor (and that was ed!), an assembler, and a kernel.

In the next evolutionary step, paper teletypes were replaced by "glass teletypes." These used CRT displays instead of paper, and their keyboards started resembling modern ones. Note that these early glass teletypes did lack the scrollback buffer, thus the lines that have been scrolled away are gone forever. In some sense, this was a downgrade from paper rolls. On the other hand, since typed characters were appearing on a screen, it was possible to make in place corrections in the typed command text, and even move the cursor left and right in order to correct typos in the middle of the command—no more retyping!

The capabilities provided by this new type of terminals have spurred improvements to ed editor. First, it has got a command for showing a whole page of text from the file being edited, taking advantage of the silent nature of video terminals. This version was called em. Note that em still had to be conservative in what it displays because the connection line between the terminal and the computer was often painfully slow. Implementing in-place editing for a whole document—a "visual" editing—was not yet possible.

A lot of standard Unix utilities like bash, cat, du still operate in a similar line-oriented mode and thus are still technically compatible with typewriter-style terminals. In fact, Emacs exploits this fact by emulating a "dumb" terminal (that's another name for the kind of terminal that only understands basic cursor moving commands) in its "shell" mode. But in fact, since Emacs works on a real computer, its shell mode is much smarter, because it can hold the screen history of your entire session, and you can go back to any previous command, change it as needed, and send again.

Back in time, similar capabilities had also appeared in new generations of terminals that got their own CPU and RAM, and thus could hold in their memory much more than just one screen of text. They also got colors! The companies making them have coined the term "smart terminal." The terminal technologies started to be a hot topic among technology companies (very much like AI these days), and there was a "Cambrian explosion" of terminal models, each with their own set of features.

These new features of smart terminals gave birth to a whole new set of control commands. Since the controlled display area had expanded from a single line into a two-dimensional array, there were commands that control the cursor position on the screen, and perform screen clearing and scrolling. For compatibility, and due to technical constraints, these new commands were not single characters anymore (as "backspace" and "carriage return" are), but rather entire sequences of characters, starting with the "escape" command symbol.

The terminal controlling commands were still sent inline with the printable symbols. When a smart terminal saw a command, it processed it immediately. This was usually resulting in a cursor position change, or the current color change, or enabling bold font, or something else (note that some similarity with HTML language can be noted, except that unlike HTML tags, control commands do not have a closing pair). If it was a symbol character outside of the command, the terminal just printed it. To get a sense of how many terminal models and various types commands were there, take look at the "terminal information database" here.

Finally, smart terminals created possibility for visual editing, and the ex editor was reworked into vi. The first versions of vi were implemented by relying on ex running in visual mode. You could still use the same commands that ex has inherited from ed, but you could also navigate and scroll the document you are editing. The modern versions of vi still use these two modes of operation.

Of course, other visual versions of existing UNIX system utilities started to appear, for example, top is a visual interactive version of ps (processes control), and more and less are visual pagers, offering an alternative to line-oriented cat.

By the way, that terminal information database I mentioned above was not created just for lessons in computer history. In fact, it was solving the problem of standardization of the "terminals zoo". When a visual program runs, it needs to know what the terminal is capable of, and also what is the exact control characters sequence for each terminal command (remember that there were hundreds of smart terminal models). There was a library called curses which acted as a translator between a program and a terminal. Unfortunately, a lot of modern command-line scripts and utilities are unaware of this translation mechanism, and use control sequences "blindly", assuming that the terminal is able to interpret them correctly. In part, this works because these days we use "terminal emulator" programs that typically use the same set of control characters. But when this is not the case, the user starts seeing a flurry of cryptic sequences that start with ^[ (the escape character) in the program's output.

Besides the need for standardization, another interesting engineering aspect that had emerged was the ability of terminal virtualization. Since, as I mentioned previously, terminal control characters are in the same stream with program's output, and user cursor control commands are in the same stream with program's input, the standard UNIX mechanism for I/O streams redirection created a possibility of emulating terminal behavior within a visual program. Normally a visual program assumes that it uses the entire screen of a physical terminal (the terminal provides its dimensions in rows and columns). But if one program launches another, it can direct the I/O streams of the child process into itself, and maintain a virtual terminal for it. For example, the parent program may run several child processes and maintain a virtual screen for each of them (this is what the utility called screen does). Or it can allocate a subsection of the terminal (half of a screen, for example) to a child process, and run two of them side by side. This kind of virtual terminal manager programs is called "terminal multiplexer", with tmux being a well known example.

An interesting question emerges: since there is only one user, with only one keyboard, if a terminal multiplexer is running two other visual programs side by side, which one is receiving the input? The answer is—the input is received by the parent program, which then sends it to the child process which currently has "focus." To give the user the ability to switch focus, or send any other commands to the parent program, they need to prepend their input with a "control sequence" (or "escape sequence"). As an example, for screen, the default control sequence is Ctrl-a. When screen receives it, it understands that it does not need to retranslate what follows this command to the child process, but rather interpret it itself.

The virtualization can be arbitrarily nested. For example, you can launch screen, and inside it launch another instance of it, but you need to be careful with control sequences. screen has a command "send escape command", thus in order to send a control command to the nested screen we send the command "send escape sequence" which is interpreted first by the parent screen, and after it executes it (and thus sends the escape further down), the nested screen enters the command interpretation mode. If you need to send control commands to the nested screen frequently, you should really change the default "escape sequence" for it (to Ctrl-b, for example) so that the parent screen sends it directly.

Another problem that virtual terminal programs solve is working around the fact that in Unix, a process can only be "bound" to one terminal only. This reflected the normal use case of a user logging from a terminal into the OS, and when they log out, all their processes are automatically terminated. The only possibility for a process to outlive its terminal is to "detach" from it and become a "daemon" process. In fact, most of the OS own processes are daemons, so they can run even if no users are logged in. However, users cannot easily interact with a daemon—normally, the output from it goes into a log file, and commands are sent to the daemon using UNIX signals.

Terminal multiplexers / emulators created a new possibility of user session persistence. Since they launch the user's program under a virtual terminal, it is not bound to a physical terminal, and can run until next system restart, like a daemon. However, since the multiplexer also has a user-visible part, that user program can interact with the user normally. And in fact, only that user-visible part of the terminal multiplexer gets terminated if the user's physical terminal gets disconnected from the OS. When the user reconnects, it can re-attach to the already running session of screen, and continue their work. But this feature makes the implementation of screen and tmux rather complicated because the user can reconnect using a different kind of terminal. Thus, essentially the terminal multiplexer needs to perform adaptation of terminal control sequences that the user's visual program is sending to the virtual terminal into equivalent control sequences of the current physical terminal.

What is Wrong with Terminal Emulation in Emacs?

With that history in mind, I can explain the Big Friction Point that I had with running command-line programs under Emacs.

Emacs entered the text editor scene much later than vi, and it was designed right from the start to be a visual editor, so it does not have the line-oriented mode like vi does. Moreover, since Emacs pretends to be an operating system in itself (that's another popular hacker's joke), it offers both dumb terminal emulators (the "shell" mode, and the "compilation" mode), as well as full smart (or visual terminal) emulators. That means, you can run vi inside Emacs if you wish to. The caveat with visual terminal emulation in Emacs is that it goes against two important principles of its design.

First, very much like Macintosh OS design, Emacs strives for having unified key mappings across its editing modes, that's to avoid interrupting users "mental flow." However, a vi instance running inside an Emacs virtual terminal still expects standard vi input. And it will assume that it has entire control of the user's input and output. So, as it was discussed above on the example of screen, the terminal emulator of Emacs normally needs to capture entire user input and send it to vi. And in order to interrupt that, the user needs to send some "escape" command to Emacs. Thus, visual terminal emulators in Emacs also need to have at least two "modes", and this is inconvenient, because it breaks normal key chord control for the user. The built-in emulator called term calls these modes char (in which the user input goes into the child process) and line (in which the child process does not receive any input and the user can manipulate its output using normal Emacs commands). And if you are interacting with the nested app and the rest of Emacs, you need to switch them frequently.

The second thing of visual terminal emulation that goes against Emacs design, is that a program designed for a smart terminal can only have one output view (recall that in the design of Unix, an interactive program can be bound to a single instance of terminal only). Although both tmux and screen do allow connecting multiple clients to the same session—this is often used for "live" or pair programming sessions—but since the program "sees" only one terminal—the virtual terminal which tmux or screen emulates—it can adjust its view to one terminal size only. There are only two viable choices for the terminal multiplexer here in terms of which terminal size it can report to the nested app: either use the size of the smallest terminal for all connected physical terminals, or report the size of the "current" one, and admit corrupt visual state on physical terminals that have non-matching size. Note that this problem is somewhat a corner case for traditional terminal multiplexers, but Emacs naturally allows viewing the same text file (which is abstracted into a "buffer") in multiple views simultaneously, this situation can happen quite naturally. And in this case, a buffer associated with a terminal for a visual program can be displayed correctly in a single view of the buffer only.

So, basically, existing terminal emulation solutions for Emacs are all of two kinds. The first kind simulates a dumb terminal (like "shell" mode does), and this allows to transform the output of the program into a normal Emacs text buffer (with colors attributes, thanks to ansi-color package). And this, in its own turn, allows this buffer to be manipulated using standard Emacs editing commands, and also allows displaying it simultaneously using views of different sizes. But if the user runs a utility that uses more "advanced" terminal control characters, the output from it can go awry. As I mentioned before, a lot of terminal-based utilities, including build tools, and even OS's own tools, do not query the terminal type and just assume that they can use arbitrary terminal displaying tricks for their fancy progress bars.

The second kind of Emacs terminal emulator provide full screen emulation. From what I have seen on various forums, a lot of Emacs users sidestep the problem of garbled output by resorting to this kind of emulation. That is, these people run their shells and builds in full terminal emulators under Emacs. Some of these emulators, like eat, offer to solve the keyboard input problem by providing a third "hybrid" mode—eat calls it semi-char—where most symbols are sent into the child process, but some are interpreted as usual by Emacs. So maybe the user can remain in the "semi-char" mode for longer time while interacting with an app running under Emacs, but once they will need, for example, to copy some output from it, and for that they will have to engage into mode switching, which can be disrupting to their mental flow.

So we see, that the hybrid solution from eat is applied on the user input side. My idea was to make a hybrid on the program's output side instead. That is, to evolve the shell mode into a third kind of terminal emulator, which still mostly supports the dumb terminal emulation mode, but allows the child process to use a subset of control characters for displaying fancy progress statuses. After all, once the long action carried by the app completes, it normally erases all its intermediate output, and the result looks very much like an output from a good old line-oriented program. To state it in another way, I don't need to run vi in my "evolved shell", but I need to be able to run apt get install and observe a normally looking progress bar instead of colorful garbage interleaved with control characters that the Emacs "shell mode" does not understand.

By the way, as I read in the materials about the unsuccessful planned successor of Unix OS—the Plan 9 OS—its terminal (called 9term) was built around similar ideas of considering program output as buffers of text, and dropping support for terminal control sequences completely. 9term was behaving more like Emacs shell or eshell modes, representing the program output as a stream of text and making the terminal basically a text editor which allows the user to work both with the history of commands and with the program output as if they were a text file. In Plan 9, if someone needed a visual program, they had to make it a GUI app, and building "TUI" interfaces was considered a thing of the past.

The Helping Hand of AI

By then, I had already been using AI in "assistant" mode for quite a while. That means asking questions and then copy-pasting fragments of AI-generated code, basically it's a replacement for Web and forum searches. But true AI agentic coding (also known as "vibe coding") is completely different, and I had to start learning it.

Luckily, I was already experiencing something similar for a couple of years thanks to the reliance of modern tech companies on "vendors", or what is called "outsourcing." In this model, if there is a programming task that can be delegated to another company, this should be preferred to using the company's own engineers time on it. This is just basic cost reduction effort. Since outsourcing companies are located in geographical areas with lower labor costs, they can offer much lower hourly rate.

So, I was already doing a lot of programming tasks in the manner where I was just formulating some high-level idea of what should be done, and how the produced code should be tested. Then I was reviewing the code contributions from my vendors, and passing them back my comments. Does that sound familiar? Right, this is very similar to how "vibe coding" works, with two major differences: the cycle speed with vendors is typically longer, measured in days, thus you don't get that "vibe" feeling, and the capabilities of human vendor programmers used to be better than of AI agents. I said "used to be" because with late 2025 models I had noticed a big shift in their programming abilities.

I decided the time was right to unleash the power of those new AI models to help me to finally fix my Big Annoying Thing with Emacs. Since I knew what I need to achieve, I did not have to ask AI to come up with an "implementation plan." Instead, I started with writing tests for my new Emacs mode extension. For this, I still used AI in assistant mode, and it was really helpful in constructing these pesky ANSI escape sequences for the scenarios that I cared about. The LLM was also able to analyze a full output from apt package installation session in order to find out which terminal control sequences it uses, and create a script which emulates its output.

Having these tests, I had established a "continuous integration" (CI) loop where I was loading the code of my extension into Emacs (by this time, there was no code yet), launching those test scripts, and comparing the results with "golden" outputs which I have produced with screen. Time to unleash a fully autonomous AI coding!

This is where the real fun began. I was using Gemini CLI, and at first I've made a mistake of letting it use the 2.5 version of the LLM. And it was really struggling, to the point that it could not even write a correct Lisp code. Lisp syntax is very minimalist and consists of lots of parentheses that need to be balanced. Surprisingly, Gemini 2.5 had big problems with that. It actually broke my CI loop at first, because it was writing code that was causing Emacs to fail to load the module, or to hang up completely. This was something I had never experienced with vendors (I told you, so far humans were better programmers than AI). After I made my CI loop more resilient, the AI has entered its own loop by endlessly trying to fix the Lisp syntax, and never succeeding, eventually falling into a mode when it was continuously streaming its looping chain of thought into my terminal. Having wasted a couple of hours on this, I was about to give up and was considering to switch back to assistant mode of coding.

But then I've done two things: had switched to the "latest preview" model of Gemini, which was 3 at that time, and, again with help of AI, improved the project instructions, specifically insisting that the agent writes "Parinfer-compatible" code, and verifies it thoroughly. This was a night and day improvement—the agent finally managed to fix almost all failing tests by writing correct code, and I started feeling good vibes.

Over a week, during my spare time, we had finished the implementation to the point that I could really run my build script in Emacs "compilation" buffer and the output was looking exactly as it looks on a terminal with full capabilities. During this period, I was following the usual principles of Test-Driven Development: always write the test first, make sure the changes fix it, and do not regress anything else, then do a refactoring of code, and of test. So it's like a real engineering cycle, except that I only had to type in plain English—no more coding myself.

I also realized that the AI agent is capable not only of writing code and tests, but actually investigating problems, and it can even write their own tools for that—like a real human programmer! At that point my feelings towards the agent shifted, and I started to consider them as my colleague, at least, like a robotic colleague, something like WALL-E robot, maybe. I still had to help this robot sometimes to fix Emacs Lisp parenthesis issues. That was mainly because I wanted to save my time, and also money.

Yes, one thing I would like to mention is the cost of this exercise. I have ended up spending about $55 on the inference, which is of course not a lot, but you need to realize that this wasn't a big project either. So when I'm reading about huge projects that involve hierarchies of AI agents, I think they can burn a lot of money each day! Besides all the useful work that the agents do, when a problem gets really hard for them, they can easily end up dwindling down into a "confusion spiral," and that is all at your expense! So be careful—I really would not let a swarm of agents to work without close human supervision.

Parting Thoughts

If you are interested, the resulting Emacs extension is here. I called it comint-9term to indicate that it extends comint (command interpreter) mode of Emacs, and it delivers the spirit of the 9term terminal from the Plan 9 OS.

The code is complete now, I'm just planning to continue fixing any edge case scenarios that I might encounter. After all, as I have explained above, this hybrid terminal scenario is a bit unusual, and operates on a boundary between dumb and smart terminals, so some scripts or programs with super creative approach to progress displaying may cause issues. But the AI has added "tracing" sub-mode, so whenever that happens, I can grab a trace, and give it to my AI agent for analysis.

From this "vibe coding" experience, and also from reading experiences of other people, I think this new human-computer interaction mode will stay. Even if some of the companies that are currently making "frontier" LLMs will collapse due to economic reasons, the technology is out there, and people will find ways to make it more economical and efficient.

AI is definitely the new way for writing computer programs, and I think it may change how we treat our phones (or TVs, or cars). Since the appearance of the first iPhone, it was always annoying me that smartphones and tablets were always treated as "embedded" devices, which means, you had to program them using a "real" computer, despite the fact that the CPU power of modern phones is orders of magnitude greater than the supercomputers of the 1980s, let alone the personal computers. Compared to a Z80 (the heart of ZX Spectrum), a modern phone is like a starship compared to a bicycle.

I know, one big obstacle of using your phone for programming was absence of a real keyboard. Since phones do not have a convenient keyboard, writing a program for them in a "traditional" way was a pain. But not anymore! Finally, with AI it's possible to write a program for your phone using only your phone (in theory, at least), by talking to an agent who is building and debugging the app for you. Thus, personal devices can become something like home computers have become for kids 40 years ago. So, despite all the "AI gloom" regarding its economic effects, I look into the future with big enthusiasm.