(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.
