Native Shell Window [$5]

[gingerBill]

As much as I love Sublime and Lime, Emacs does have one very useful feature: shell-mode. M-x shell will invoke a shell window. With Sublime, I usually have Sublime open and a terminal window open. I know there are some plugins available that so similar things but they tend to not do it exactly the same/well.

Would anyone else like this feature or is just best to leave it as a plugin?

--- There is a **[$5 open bounty](https://www.bountysource.com/issues/11860452-native-shell-window?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F282001&utm_medium=issues&utm_source=github).

[randy3k]

:+1

[Evpok]

What would really be nice is a shell panel, similar to the konsolepart panel in Kate, that syncs with the current file.

[kennylevinsen]

If I recall correctly, M-x shell doesn't give you a full terminal emulator, but a sort of hacky shell. I might be wrong, though.

It would be nice if the backend could handle a (full) terminal emulator buffer somehow. There is a bit of complexity regarding multiple views being open and looking at the same buffer, as the application needs to know the exact size of the view. Other than that, it shouldn't be too bad.

[gingerBill]

@Joushou You seem to be correct. There also seems to be eshell which is written entirely in emacs-lisp.

[derhuerst]

Maybe my question is irrelevant and sightly out of scope because I don't follow this project too closely, but why not use Bash?

[kennylevinsen]

Bash is a shell, not a terminal. The topic is whether we should have a terminal emulator built in for convenience, so that you could use lime's buffer handling and such. One can always go to a different terminal, but as someone using NeoVim's term buffer every day, I find the built in support to be much more convenient.

[BarronKane]

I agree that it should be closely integrated, the problem arises when different operating systems implement emulators in different ways so we'd have to add libraries to support them or make our own integration with qml and some hacking like what @Joushou said. Visual studio has been plagued by this issue for ages on windows, so they just opted to call it externally which is just clunky.

[kennylevinsen]

There are a few ways to do terminal emulation, but it's all "fairly" standardized these days (still a bit nasty, but it's doable, with many libraries providing you the functionality), as you identify your emulator with the TERM environment variable, so that "advanced" applications know what features you provide and how. Windows Command Prompt may be funky, but when one uses full-screen tools in that prompt, it's probably a UNIX tool that can handle a proper terminal anyway. You don't need any fancy features to use "normal" tools.

I don't think we need any hacky integration with QML at all. A terminal emulator is just a buffer of a certain with and size, where the emulator translates command sequences into things like colored text or cursor moves. QML doesn't need to know anything about it - it should just display the content of the buffer, and feed the keyboard input back to the backend. This way, any frontend can show terminal content, completely unaware of what's going on.

The "annoying" thing is that the buffer needs to know when it has been resized, and there has to be some handling of when 2 views are open to the same buffer (Which gets to be the "master" that decides the size?), as the emulator has to send a SIGWINCH signal to the process it is displaying, letting it resize properly to fit the new "window" size.

[BarronKane]

I get what you're saying. Just a single fixed emulator isn't much of a problem, it's when we want to split and customize it on a more dynamic level that makes it difficult.