Vernunftzentrum

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?

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?

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.

I've made a mock-up to illustrate my ideas about the next-gen terminal experience!

Featuring:
• the pathbar
• username, hostname and git branch displayed in the UI, shrinking the shell prompt back to just a $
• commands as cards
• syntax highlighting, including graying out the output a bit to differentiate it from commands themselves
• autocompletion (displayed in a native widget)
• built-in error handling options
• the time each command took (on the right)

@bugaevc That's a nice idea!

I would highlight the commands differently, the output of commands is important and reducing the contrast here is counterproductive imho. Maybe just use a different color or underline them? cursive? IDK

@grainloom @bugaevc Both of you are not contradicting each other there :)

@grainloom @bugaevc

TBH all these fancy shell prompts and such are getting pretty ridiculous. If you are using a graphical UI it should take advantage of that. So far all we have are some weird terminal emulators with a baud rate setting.

That has to change

@grainloom @bugaevc

None of this is portable in any way. That's why we are still stuck with what we have. Every wanted to know how the graphical shells change their title? There are some escape sequences for that. Icky stuff...
replies
0
announces
0
likes
1

@lanodan @Shamar @bugaevc

@grainloom


Or plan9's htmlfmt

@lanodan @Shamar @grainloom
@bugaevc


Escape sequences on their own are dangerous enough.

All the widgets are interactive! You can click on the pathbar to `cd`, and the popovers on the bottom bar let you basically do `ssh`, `su` and `git checkout`; the git one additionally allows you to open the current repo in Gitg or in Builder.

@grainloom @Shamar @lanodan @bugaevc @lord

I'd love to see more sixel support :)

@grainloom @Shamar @lanodan @bugaevc @lord

On a more serious note: the disability to just render images on screen is the serial line interface heritage.

Plan 9's graphical windows are just graphical windows, you can blit anything on them. Even the shell could, no special support required (apart from generating the right pixels).

@bugaevc How is clicking supposed to work via SSH?

@mbirth it sends commands to the shell (I imagine some escape sequence-based protocol, but I haven't thought about the specifics too much). See my other replies in this thread where I went into some more details about how this protocol should be shell- and toolkit-independent and how it somewhat resembles DWDs.

@bugaevc love the concept. If this actually get made I'd definitely try it out. If it's in I might hack on it too 😉

@bugaevc love the concept. If this actually get made I'd definitely try it out. If it's in I might hack on it too ablobcatheart

@bugaevc
KDE's Dolphin has such path integration in its terminal pane.

And yeah, as far as I can tell, it sends a Ctrl+C to clear/cancel any typed-in command and then just executes "cd /path/to/what/was/clicked".

It also syncs the other way, so when you cd in the terminal, it navigates the file manager to that path, too.
I'm guessing, it monitors the CWD of the shell process to figure that out. But that obviously breaks when you spawn a new shell, so wouldn't work for SSH either...
@mbirth