Agree. Although I can see how the idea of "first principles" can be a very difficult starting point. A blank sheet of paper is a scary monster.
There's a huge breadth and depth of non-"desktop" GUIs out there, some (like smartphones) are even wildly successful. It's good to explore them for inspiration. Some of my favourites:
- Arcan (https://arcan-fe.com/about/) - I won't attempt to summarize, just dive in!
- SailfishOS (https://sailfishos.org/) - mobile UI focused on interaction through gestures / swipes; I've used it as my daily driver for a couple years.
- Speaking of mobiles, classic Nokia UIs allowed you to navigate to a specific item in the menu by pressing the corresponding digit on the dial pad. Once you learned where a particular item is, accessing e.g. your SMS inbox was extremely quick.
- Apple Watch / WatchOS (https://www.apple.com/watchos/) - I've always loved the idea of a device where one of the primary interaction methods was a wheel/dial of some sort. The watch even gives you context-sensitive tactile feedback.
- ZUIs in general (https://en.wikipedia.org/wiki/Zooming_user_interface) and the work of Jef Raskin in particular: https://en.wikipedia.org/wiki/Archy_(software) - this is the guy who helped design the Macintosh, but his other work took a radically different route.
- Magit (https://magit.vc/). Many common git operations are reduced to a couple of keystrokes; the obscure features are more discoverable, and the cumbersome procedures (such as rebasing, or staging individual hunks) become simple and intuitive. Also check out transient (https://github.com/magit/transient), which is the "UI toolkit" that powers Magit.
Magit itself is powered by <https://github.com/magit/transient>, which I see more as an interaction paradigm than a library; it could enable more ergonomic interaction with other stateful tools that are typically native to the command line / terminal (such as docker/kubectl, systemctl, mpd/mpc, etc). Rather than using Emacs as a middle layer, Transient could build on top of pluggable native toolkit backends, such as Cocoa, Gtk, Win32, or even web or a terminal.
We continue investing into terminals because the terminal remains the lowest common denominator of interacting with a computer. On the other end of the spectrum we have Electron, which has very clear and obvious downsides. I think there is low-hanging fruit with amazing ROI somewhere in the middle, and Magit/Transient is an example of what it could be.
> However, I personally don’t use this capability of shell a lot: 90% of commands I enter are simpler than some `cmd | rg pattern`. > (kbd "C-c") doesn’t work as it works in every other application.
So rebind it? Even terminal emulators allow for rebinding of keybindings, and so does emacs.
> I launch GUI version of Emacs: the terminal one changes some keybindings, which is confusing to me. For example, I have splits inside emacs, and inside my terminal as well, and I just get confused as to which shortcut I should use.
IMHE the solution is to decide which tiling manager you wish to you use (my experience is informed by using i3 to tile and sometimes emacs). 99% times I use my i3 to tile, and emacs only splits in half (C-x 2 or C-x 3 depending on what I need and how wide the emacs window is)
> Why can’t I type cargo test, Enter, exa -l, Enter and have this program to automatically create the split?
What you are looking for is `cargo test &`, `fg`, `bg`, and (kbd "C-z"), no? The ability to suspend and bring to foreground or background enables this kind of 1. run tests 2. list files. My own experience suggest that how I create the split is dependent on some, potentially implicit, context.
> Additionally, while magit awesome, I want an option to use such interface for all my utilities. Like, for tar?
Firmly agree, and I believe this is what the transient[1] package is for.
> extensible application container, a-la Emacs or Eclipse, but focused for a shell use-case
Emacs /is/ focused for shell-use case, at least in my understanding and use of it.
> A UI framework for text-based UIs, using magit as a model.
ctrl+c, ctrl+v and friends should work as expected. cua-mode enables the "normal" copy and paste bindings.
> A tilling frame management, again, like the one in Emacs (and golden-ratio should be default).
What's wrong with `C-x 1`, `C-x 2`, `C-x 3`?
> A prompt, which is always available, and smartly (without blocking, splitting screen if necessary) spawns new processlets.
Isn't this what M-x is or would it taking up the bottom line disqualify it for "splitting". Regarding blocking, I do agree it's very annoying to have emacs become unresponsive.
> An API to let processlets interact with text UI.
I would assume that there is something lacking from emacs lisp api[2] for manipulating emacs, but it's not clear what they are from this authors perspective.
> A plugin marketplace (versions, dependencies, lockfile, backwards compatibility).
What is wrong with melpa, quelpa, emacs-wiki, et al?
> It doesn’t define out-of-process plugin API (things like hyperlinking output).
It sounds like that would require the out-of-process layer (shell) to be as expressive as the in process layer. For instance, emacs can link to files, and new custom link styles, but my terminal is loathe to support http(s)/(s)ftp, and I presume is not easily extensible (as emacs) to new protocols.
> Its main focus is text editing.
Everything already communicates in text, it's not clear there is a obvious alternative or what would suceed text editing for this use-case.
> Its defaults are not really great (fish shell is a great project to learn from here).
Perhaps, but the gnu emacs community seem to profess a "we-came-first" mentality for conflicts with emacs defaults and the 'wider computing experience'.
> ctrl+c, ctrl+v do not work by default, M-x is not really remappable.
cua-mode and false, I have m-x remaped to use helm.
1: https://github.com/magit/transient 2: https://www.gnu.org/software/emacs/manual/html_mono/elisp.ht...