First, let's start with a bit of background.
I like using a terminal / console. The direct interaction and expressiveness that a command line gives me is very powerful, and efficient. I'm writing this post in vim, using restructured text. I do all my file management in a console window, directly in the shell.
So when I think about what a 'better' terminal would be, I don't mean to replace it with something that fundamentally changes the interaction model. For some, a better terminal would be more like a notebook, with rerunable, editable commands, able to embed images, links, and videos. Interactable with a mouse. That escapes the bounds of what I believe to be generally useful as a replacement for existing terminals. (The IPython Notebook is a very good example of something that is 'like' a terminal, or interactive console, but serves a different purpose and audience.)
All that being said, there are definitely limitations of current terminal emulators that I believe are worth addressing. They fall into a couple of broad categories, with some basic requirements:
These requirements are based on my usage, which is from the perspective of a software developer, with a native language of English, but an interest in correct and pleasant typography, linguistics, and mathematics.
Many of these requirements are born out of the usage of a modern terminal emulator and its environment, given the differences between the current usage and the historical context in which the terminals were developed.
A modern terminal emulator is a piece of software responsible for interacting with the I/O system in some fashion (either through a graphical environment like X, through a kernel primitive like Linux's CONFIG_VT, etc.) and interacting in a specified way with software run on that terminal. It functions as a basic API layer for certain kinds of software.
This is different than the historical usage, which was that a terminal was a device attached to a computer (generally over a serial line) that provided access to the computer, generally a multi-user machine. As such, the I/O system was only able to communicate in-band over a stream of bytes, generally, and many of the limitations of current terminal emulators are a direct result of this arrangement.
Even in the case of a remote terminal, we now have much higher bandwidth in most cases, so a more robust terminal protocol, between software and the I/O system is desirable. Additionally, given no compatibility constraints, we can define an out-of-band mechanism for control of the terminal, rather than needing to rely on a complex and ambiguous stream of bytes for all communications.
I don't have a clear idea of a design, I am only outlining what I feel are the requirements of a 'better' terminal.
Thanks for reading.