command line interfaces should be less like vt100s and more like chat apps
the vt100 is a dumb terminal, right? it knows nothing about what it's actually displaying - whats input, whats output, where they all begin, etc. you can't edit a command/input in a repl, you press the up key and you make changes and you run it again. if you turned to a chat app though, there's a clear in/out distinction!
you could associate inputs with their outputs! rather than pressing the up arrow 5 times then 4 times then 3, you could just group your input, like a chat app!
the reason people aren't using clis and terminals isnt because theyre dumb or stupid or technically illiterate or whatever, its because they suck! look at discord bots! telegram bots! theyre massively used, and theyre no different to a cli!
technologically, something like this will probably end up *smaller* than a terminal emulator - look at st and xterm for the smallest terminals out there (theyre huge!)
both technically and in terms of accessibility, it's superior!
@eris so maybe a conversational ui in forth will do?
Intresting. Something I liked about telegram bots is the ability to create keyboards for earch step.
@eris I stil have to wrap my head around apl. Feels like having spanish names in my mind for symbols should help.
@eris The différence is also that using command line, you need to remember all the commands and all their parameters. With GUI, it's just a list that you can select from.
@narF command line interfaces inevitably will exist; GUIs can't cover everything. this is about making command lines better than they are now; tied down by legacy
@eris haha sorry. I'm not super well versed in command line. I might have missed your point.
I guess what I'm saying is that we should take what is good about GUI and apply it to command line.
The Fish shell is good for that. It automatically displays help while typing commands, to help remembering the order of arguments and stuff like that.
@eris vt100s were line-oriented, slow, and ttys in linux are xterm-compatible. So inertia all the way from the 60s-70s is the problem.
It's possible to write more dynamic stuff, but it's just more complicated and because usually there's no library to abstract it you opt for legacy. I think the most "advanced" lib I've seen is https://github.com/dankamongmen/notcurses
@epilys i dont get it; im talking about throwing out everything related to ttys, current shells, etc
@eris I have many thoughts on this subject:
1. Messenger app as CLI is a brilliant idea that I wish I'd thought of.
2. Tech industry marketing has pushed the idea that CLI == hard since the mid *1980s* and most people have internalized this. IMO, that's the main reason most people don't use CLIs.
Note: I'm not saying the people who buy into this are dumb, just that learning this stuff is too much effort when they just want to write their friggin' essay and get on with their lives.
The big lie here is not that CLIs need up-front learning but that that learning is a *huge* amount of work. It isn't and it's often less so than figuring out a bad GUI app.
3. The version of this that will gain mainstream acceptance is still going to need to be backward compatible with (at least) XTerm just because of the huge existing code base that depends on this. There are ways to do this cleanly and seamlessly, though.
4. The big problem with the current state of the art is that the shell doesn't know that it's part of a GUI. Terminal emulators are pretty good so things are good enough for most people, but there are the irritating edge cases (e.g. the shell doesn't know its input is pasted and will just parse it as usual, the terminal doesn't realize it's seeing garbage program output, etc.) A lot of this could be done better if there was integration.
@christa ive talked about integration in my ramblings against shells and terminal emulators! (, but you might not have seen them)
@eris I'm a pretty new follower, so no.
I think this is one of those things where what we have is good enough that there's not a lot of drive to fix it.
I'd also like a clean way to migrate my long command lines into something more persistent. If the prompt were a functional multi-line editor, the GUI could detect more complex commands and store them in a special history with versioning, tagging, storage, etc. That would give me a persistent tool box.
It would detect pasted text with newlines and *NOT RUN IT AS A COMMAND*.
It could make long output foldable and deletable so it doesn't bury previous commands' useful output.
See "Bracketed Paste Mode" for your shell/terminal to prevent running pasted strings as a command
Also, some shells have the option to edit the current command in your editor. ZSH also has a vi mode: it lets you edit the command with vi shortcuts without leaving the shell. I have Esc+space set to launch vim with the command if I want to do something more advanced.
For previous output, you want scrollback. A terminal multiplex like tmux saves previous lines up to a configurable limit.
@christa These are all "low-tech" solutions to real problems. I too wish for a modern terminal experience.
@epilys I didn't know about bracketed paste mode; definitely need to check that out.
FWIW, editing the command line in a text editor is the opposite of what I want. It lets me use a heavyweight tool to edit ephemeral code while I want a seamless way to edit (potentially) valuable code.
But yeah, these all make the situation much less terrible than it could bel.
Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.