What I would really like to see is more integration between terminal emulator and the shell (and commands you run in it). Currently in Fedora/GNOME the shell prompt is set up to make the terminal notify you (with a native GUI notification) about long running commands completing. That's cool, but we could go so much further.

For one, the shell could let the terminal know the current directory, hostname, username, git branch, current command, last command status, etc. etc.

The terminal then would display that info in its GUI, and perhaps even let you interact with it (imagine a GtkPopover for changing git branches and a Nautilus-like pathbar for the cwd!) We could then shrink back the prompt back to a simple dollar sign.

That would already be infinitely cool, but it gets better.

What if the shell could send its completions to the terminal and the terminal would display them in a native autocomplete widget (like in Builder)?

What if the terminal could track where the output of each command is and allow you to collapse/expand it with a GtkExpander? What if it could visually present each command and its output as this expandable card, along with the time it was issued and the time it took to run (like `time` outputs) and its exist code? And if it failed, paint that card red? And if it segfaulted, add a button to duck duck go the error, run ABRT or even run dnf debuginfo-install and coredumpctl gdb?

Sergey Bugaev

What if pagers like `less` could make use of the native scrolling instead of faking it by moving lines? What if `man` rendered the content to HTML (or GTK's native markup format) and presented it as an actual page, sort of like what you get by running `yelp man:foo` but right there in the terminal?

What if `ls` could make use of the native list/table widget and render file icons, just like Nautilus? What if you could expand the folders it outputs right there using mouse and get a tree view?

@bugaevc The next step is enabling JavaScript, and then your terminal is just another web browser.

@deshipu uh no please, no JavaScript. HTML is a great markup format for simple text documents. You don't have to abuse it for layout like they do on the web.

Don't tell me that fish or vim already display completions in a pop-up using some magical pseudographics. I'm not talking about abusing the old grid-of-characters model of terminals. I'm talking about making the shell and the terminal communicate better so we can use *native* (e.g. GTK+) widgets for what is traditionally done using text-based interfaces.

Mind, just like currently `ls` knows to columnize and colorize its output and `grep` knows to highlight the matches in red *when outputting to a terminal*, but fall back to plain text when piped to something, what I'm describing here would simply fall back to plain text when piped or run in a less magical terminal. So this is about enhancing the existing tools, not about breaking compatibility in any way.

And at the same time that would really get the terminal/shell experience from "emulating ancient hardware to be able to do stuff we haven't yet made a GUI for" to "a way to do advanced stuff with your computer using a command-based interface".

That would truly be a command-based interface for the 21th century. That would be something I'd be proud, not ashamed, to show off to Windows users as the advanced way to tune your system.

@bugaevc vaguely remember a project like this from a long time ago, an attempt to make the terminal show specific data more "intelligently"

oh found it: github.com/unconed/TermKit
(apparently also abandoned since 2011 !)

i guess the closest i otherwise can think of is the ipython-qt console which can show graphs &c inline

@bugaevc Ah, I see you meant the same thing I did. Yeah, I think that should work.

@bugaevc As a concession to backwards compatibility, I wonder if one could do this as a sort of "font style" that can be applied to Terminal output.

So like you can set a color, what if you could set a "this is a file name" or "this line is a command" etc. and then the Terminal could use that info to parse out file paths and display them as clickable files etc.

That way it could be an optional add-on library like curses that existing shells can support.

@bugaevc iTerm2 has some of these features with it's shell integration. Unfortunately closed source only on OSX.

@bbense yeah, this is partly inspired by what iTerm2 can do (isn't it free software though?) and by github.com/railsware/upterm (nee black screen)

@bugaevc if I recall correctly, there was a really ambitious project to do this for Mac os x a few years ago. Merging gui and terminal in really interesting ways

@bugaevc there are various options for rendering man pages as HTML.

@atomicbird sure, and I do use them, but I still use `man` a lot, and that gives me an old-school pager. There are many GUI ways to list directory contents, but we all still use `ls` ever so often, don't we?

@bugaevc I meant, you could get HTML man pages from the command line if you want. You might type a different command than ‘man’ but that doesn’t seem very different.


What if standard utilities which use device independent standards could be made non-standard and inscrutable for no good reason?

@hhardy01 ad no reason: I hope I made a compelling case why this would be cool?

ad device independency: no, these tools already use device-dependent features, see terminfo

ad standards: a) of course the protocols should be standardized so you can use it with an shell and terminal emulator combination; I'm only using bash/GTK as an example b) this doesn't have to be deeply built into the utilities themselves, like that completion notification is built with a custom prompt and requires no changes in bash


"device independent" doesn't mean that "every device already works in exactly the same way"

Why in the world would it be cool for simple, standard text-only utilities which run in a command line interface to require a graphical user interface?

You realize that these changes you propose would not only have to work under gnome and gtk right?

@hhardy01 please read the rest of the post — I'm explicitly saying that they would never *require* any GUI, only make use of it when it's available. And of course the tools & the protocol they use should be toolkit- & DE-independent, I'm only using GTK+ as an example (as I've said above).

@hhardy01 Why it'd be cool? Because native GUIs are actually great, and text interfaces are not always so great. The key insight here is that GUI isn't inherently tied to the UX patterns normally used for GUI, and neither are command-based interfaces tied to a basic plain text-based UI.

@hhardy01 They are already being used with more than just plain text! Terminals and tools support and use colors, links, pseudographics, various escape sequence magic. My shell *already* sends me a native GUI notification when a command completes.

@hhardy01 seriously what, the notification thing? Yes, it's set up that way out of the box, and I've mentioned it in the very first post in this thread. See this subthread for some more details: mastodon.social/@federicomena/


No, about shells and commands, look at the thread view of these comments.

@bugaevc I think someone wrote such a shell for macOS once.

@js you have any more info? I know about TermKit and Upterm / black screen, FWIW

@bugaevc I don’t remember what it was called :(

@bugaevc It had even things like running cat on an image and displaying it inline.

@bugaevc No, definitely not iTerm. iTerm isn’t much more advanced then Terminal.app. It was a full blown graphical terminal. Unfortunately required nodejs.

@bugaevc Looking at their screenshots, it’s none of them.

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!

We adhere to an adapted version of the TootCat Code of Conduct and follow the Toot Café list of blocked instances. Ash is the admin and is supported by Fuzzface as a moderator.

Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!