Why is history just a list of strings?
Why can’t history prioritize commands used in this folder, repository, server, client, or user-defined context?
Why MoTerm?
The terminal is powerful. But it knows surprisingly little.
The traditional terminal model has survived because it is simple, portable, scriptable, and compatible. MoTerm asks whether we can preserve those strengths while addressing problems that have become obvious after decades of daily use.
Why does the terminal forget what a command meant?
It could remember whether the command succeeded, how long it ran, where it ran, and which operational context it belonged to.
Why do we document operational work separately from doing it?
If you spent forty minutes finding a working sequence, why can’t you curate the successful commands into a runbook afterward?
Why are reusable commands still mostly aliases and files?
A complex command could be saved as a structured template, edited by parameter, inserted back into the prompt, or run directly.
Why is command help mostly unstructured prose?
An optional manifest could describe arguments, types, choices, warnings, and exit codes in a form every shell can understand.
Why doesn’t the terminal understand multiple sessions?
One tab may be production, another a client task, another a long-running build. Today the terminal mostly sees unrelated character streams.
Why can’t a process simply say “I’m 65% done”?
Applications know their semantic state. A capable terminal could receive that state without forcing the program to repaint characters.
Why must richer terminal graphics pretend to be text?
Modern high-DPI displays could support an optional fine logical coordinate plane while retaining the character grid as the compatibility baseline.