Currently shell code is limited to one language. If you have bash, you can only do bash. But we could imagine a shell that understands webassembly, and hence we can use it with many languages. We could even imagine tools to inline webassembly generation, so that you can code directly in your favorite language in the shell, and it gets transparently compiled and executed.
Terminals:
I use a combination of GUI and TUI all the time. I like my mouse. I wish there were a terminal that behaves more like a file browser, with back and next button, an address bar, and a way to temporarily switch the view from text to icons to select files with the mouse then enter a command for thoses. Some file operation should also be available from a right click on a file path.
Not every shell lover wants his hands on the keyboard all the time.
> Currently shell code is limited to one language. If you have bash, you can only do bash. But we could imagine a shell that understands webassembly, and hence we can use it with many languages. We could even imagine tools to inline webassembly generation, so that you can code directly in your favorite language in the shell, and it gets transparently compiled and executed.
We might even compile directly to native code, nay, automatically identify the format and pass it to the appropriate interpreter, and then provide an interface to call arbitrary modules that conform to a particular interface―
... and then expose it as a library function so the shell can use it, let's call it execve().
Since so many languages use # for comments, we could even have a special comment that finds the interpreter for you! If only we had something like that.
> I wish there were a terminal that behaves more like a file browser
Oh man, you are gonna love this. In Plasma 5, hitting F4 in a file browser toggles a pop-up terminal in the folder you're in. As you navigate the directory tree, the shell actually follows you - and vice versa when you type `cd`! Working directory is always kept synchronized. If you split the file manager into a two-pane layout (another great feature), the terminal working directory follows whichever pane has focus. And of course you can drag files into the terminal and it pastes the path.
It's basically exactly what you asked for, and it is indeed fantastic. Plasma 5 is fantastic. Light years ahead.
But unfortunaly they discontinued it, which is a shame because indeed it's a nice feature.
However there is a limit to this conccept:
- no quake mode
- no horizontal split
- no way to manipulate the terminal shape and sessions from another terminal
- keyboard shortcuts and config options are file explorer first, terminal second
- no way to hide the explorer part. I don't want the files to always be here.
- no shell integration. I want some status such as the git repot state or the virtualenv name to appear in the bar, and the shell to remove it automatically from the prompt if I'm in GUI mode.
All in all, I'd prefer a specialized terminal, that have some file explorer features, and a real file explorer on the side, without the terminal features.
> But we could imagine a shell that understands webassembly, and hence we can use it with many languages. We could even imagine tools to inline webassembly generation, so that you can code directly in your favorite language in the shell, and it gets transparently compiled and executed.
For a shell as an interactive command interpreter, I don't see the point of it. For the shell as a programming language, you can already use any other language in its place.
> I wish there were a terminal that behaves more like a file browser, with back and next button, an address bar, and a way to temporarily switch the view from text to icons to select files with the mouse then enter a command for thoses. Some file operation should also be available from a right click on a file path.
This sounds more like the domain of a shell than a terminal. A terminal has no concept of what's generating the stream of control codes. A shell on the other hand could easily implement functionality like this.
I remember there being this shell/terminal hybrid that was a really advanced TUI. The best way I can describe it is, it was a blackboard/whiteboard you could run commands on. So you could have multiple commands running, and see their outputs scattered across the board (you could move things around with the mouse). Also had features like exploring filesystem trees, and inline images (I think). Can't remember what it was called and Google isn't helping :(
The Acme editor is sort of like that. Text frames you can drag around and organize with the mouse. You can run commands that get their own frame for output, you can launch a shell in a frame and interact that way, you can browse directory structures, and of course you can edit files. I don't think it's what you're thinking of (Oberon, maybe?) but you might find it interesting: https://research.swtch.com/acme
There have been several attempts at merge GUI and TUI, but I can't remember any that looks like the one you describes appart from the inline images and fs tree exploring.
Why is web assembly a desirable target? Wouldn't it make more sense to use LLVM IR or something that can go down to native? It don't get why, if you're compiling down to such a low level anyway, you'd want to target a bulkier runtime like wasm.
I also don't really understand why you'd want more than one language in the shell, but I guess if you wa
Shell:
Currently shell code is limited to one language. If you have bash, you can only do bash. But we could imagine a shell that understands webassembly, and hence we can use it with many languages. We could even imagine tools to inline webassembly generation, so that you can code directly in your favorite language in the shell, and it gets transparently compiled and executed.
Terminals:
I use a combination of GUI and TUI all the time. I like my mouse. I wish there were a terminal that behaves more like a file browser, with back and next button, an address bar, and a way to temporarily switch the view from text to icons to select files with the mouse then enter a command for thoses. Some file operation should also be available from a right click on a file path.
Not every shell lover wants his hands on the keyboard all the time.