thinking about terminal emulators and shells designed with the understanding that touchscreens exist
give me an MFD with tappable aliases at the very least.
give me a list of envvars I can paste the contents of by tapping their buttons. there's so much here that can be done with existing tools even
(this is a bit stream-of-consciousness writing here, and a lot of it is copied from things I noted earlier.)
honestly, I've done some brainstorming on what a shell should become, and I think I have some answers.
Ideally, you can operate this entire shell from a mouse or touchscreen, or a menu interface, without having to bring up a keyboard or open a manfile into another window, because all of the manipulable objects, shell commands, and all their possible arguments, are available from the library and browser panels, and their documentation is viewable inline.
First, some definition of what a "shell" is, opposed to a "console" or a "terminal".
A console is an interface by which one works with the computer. For equivalents on Windows: The local desktop is a console; Microsoft Management Console is a console in the Windows Desktop; Hyper-V Manager is a console within Microsoft Management Console.A terminal is an interface by which serial data, usually text, is received and generated. A VT-100 is a terminal, an IBM 3270 is a terminal, as is a terminal emulator, the Windows Terminal, KDE Konsole and Xterm.
A shell is an interface by which the programming of the machine (machine language monitor, BASIC ROM, C compiler, API) is abstracted from the user, by way of manipulating objects or commands.
The key here is that all three of them are part of a user interface. A shell can run on/to a terminal to present a console to work at.
In our case, the shell is what weâre working on defining here, though elements of the terminal (especially UI) play a part here.
This is a new shell, and it should act like it.
Anything short of outright revolutionary, in terms of shells, will land us with yet another âincompatible Bash-like with Featuresâ, like zsh, fish, dash, and others before it.
While terminal/vt100/tty serial buffer compatibility is a nice-to-have, it shouldnât be the defining feature of the shell, it shouldnât be the mandatory interface. We have a GUI, we should use it. Therefore, this will be a GUI application, unless it is launched from within a vt100-like/ANSI terminal session.
Make it a visual, and block-oriented agglutinative language.
Iâm not talking about a node-based scripting environment (like Quartz Composer, Blenderâs node graph UI, or Unrealâs Blueprint system) - Iâm focusing more on a âlegoâ, agglutinative series of code and function blocks, which can themselves contain code and function blocks.
Iâve always had this idea of doing a shell as âScratch, for adults.â
The gist of it is, you can freely enter commands line-by-line typed out, and theyâll be parsed into blocks transparently as you go along; or, you can attach together blocks to specify the operation that youâre performing, with transparent on-the-fly documentation and a menu or âlibraryâ of available commands to pull from.
This format would save to plain text, and be parsed into command blocks; or be saved as a compact token/AST form, and âreconstitutedâ on the fly.
Either way, itâs intended to be accessible to newcomers or less-experienced computer users, while not getting in the way of people who intend to program scripts for the shell like the way theyâre used to. A skilled command wizard could hide away the panels and simplify the âcoding blockâ UX to being little more than on-the-fly syntax highlighting; the code is entered by keyboard, as usual.
Reach into the desktop, and allow rich scripting through both API and UI.
This shell should also be able to comprehend and automate UI interactions, namespacing and identifying specific UI elements in terms of code, in a way thatâs less liable to breakage. Iâm thinking along the terms of AppleScript and Automator, on that end.
One UI puzzle that could be solved for automation tasks, is a drag-and-drop âconnectorâ line, which you pull from the shell window to a specific UI element, and then that element is referenced into the code transparently.
It should also be able to do object introspection on the desktop model and API, where present, to provide a cohesive scripting language to wrap around both command invocation and function calls to the API.
