Emacs in shell? Or shell into Emacs?

I'm still an emacs noob, but i'm trying to find a way to use emacs and shell at the same time. Usually, I run emacs into Terminator : Works well, but copy/paste is kinda glitchy. When I run shell into emacs, the shell is really glitchy. Is there a way to make this works better without toooo much work around? Love emacs btw EDIT because a lot of people asked how I use it : Normaly, I use emacs inside Terminator : I split the Terminator window in two and have emacs -no-window on my left and I start Ipython on my right. (I generally code in Python). The problem is that I can't copy paste easily from one window to the other in that situation. [M-W or C-maj-C]. While I could use Emacs GUI and just open a M-X shell on my right to start Ipython. Problem is : Some random text line appear in Ipython when I start Ipython from M-X shell.

I'm not 100% clear on your terms such as "shell into Emacs". I set up my Emacs so it is a direct client of my windowing system ever since X11 came out in 1812. On macOS, it is rather trivial to build emacs with "NextStep" support (Mac GUI) or you can [download](https://emacsformacosx.com) it. I am pretty sure that is true for Windows and Linux. Having Emacs as a direct client of your window server, to me, is a huge gain. I still have a shell window(s) open. But I also often have a "shell" opened within Emacs. Here is the help for `shell`: > shell is an autoloaded interactive byte-compiled Lisp function in > ‘shell.el’. > > It is bound to <menu-bar> <tools> <shell-commands> > <interactive-shell>. > > (shell &optional BUFFER) > > Run an inferior shell, with I/O through BUFFER (which defaults to ‘*shell*’). > Interactively, a prefix arg means to prompt for BUFFER. > If ‘default-directory’ is a remote file name, it is also prompted > to change if called with a prefix arg. > > If BUFFER exists but shell process is not running, make new shell. > If BUFFER exists and shell process is running, just switch to BUFFER. > Program used comes from variable ‘explicit-shell-file-name’, > or (if that is nil) from the ESHELL environment variable, > or (if that is nil) from ‘shell-file-name’. > If a file ‘~/.emacs_SHELLNAME’ exists, or ‘~/.emacs.d/init_SHELLNAME.sh’, > it is given as initial input (but this may be lost, due to a timing > error, if the shell discards input when it starts up). > The buffer is put in Shell mode, giving commands for sending input > and controlling the subjobs of the shell. See ‘shell-mode’. > See also the variable ‘shell-prompt-pattern’. > > To specify a coding system for converting non-ASCII characters > in the input and output to the shell, use C-x RET c > before M-x shell. You can also specify this with C-x RET p > in the shell buffer, after you start the shell. > The default comes from ‘process-coding-system-alist’ and > ‘default-process-coding-system’. > > The shell file name (sans directories) is used to make a symbol name > such as ‘explicit-csh-args’. If that symbol is a variable, > its value is used as a list of arguments when invoking the shell. > Otherwise, one argument ‘-i’ is passed to the shell. > > Make the shell buffer the current buffer, and return it. > > (Type C-h m in the shell buffer for a list of commands.) > > Probably introduced at or before Emacs version 1.1. But recently I've switched to `eshell`. > eshell is an autoloaded interactive Lisp function in ‘eshell.el’. > > (eshell &optional ARG) > > Create an interactive Eshell buffer. > Start a new Eshell session, or switch to an already active > session. Return the buffer selected (or created). > > With a nonnumeric prefix arg, create a new session. > > With a numeric prefix arg (as in ‘C-u 42 M-x eshell’), switch > to the session with that number, or create it if it doesn’t > already exist. > > The buffer name used for Eshell sessions is determined by the > value of ‘eshell-buffer-name’, which see. > > Eshell is a shell-like command interpreter. For more > information on Eshell, see Info node ‘(eshell)Top’. > > Probably introduced at or before Emacs version 21.1. And [Mastering eshell](https://www.masteringemacs.org/article/complete-guide-mastering-eshell) helped me in that area. `eshell` is what I've been using for the past few months. My advice is to tip toe slowly into Emacs and learn it over time. You will soon discover [Tramp Mode](https://www.emacswiki.org/emacs/TrampMode) which helps tremendously for working on remote system as well as inside containers. But... go slow. Pick up a few new things each week rather than try and ingest all of Emacs in one go.

If I’m understanding correctly, give M-x eshell inside emacs a try.

Vterm (and vterm-multi if you want multiple terminal buffers) is the best normal terminal experience in Emacs.

Tried M-x shell and didn't like it. Gonna try eshell! Thanks for the answer

Gonna try this! Thanks for the answer!

shell is bad, term is bad, ansi-term was "okay" but still really glitchy … but vterm is where it's at. :)

I'm currently using doom emacs (on my humble experience there much more stuff in it that just works out of the box) and run eshell (which is emacs own shell) inside it. I had issues with it, but somehow managed to resolve them. I think it was that eshell doesn't read any .bashrc, .bash_profile, etc. You have to set up it in emacs config files. And I'm not sure at all that I won't face some other issues later. However, if you have issues with eshell, there is a regular shell (`M-x shell`) that works like a terminal. I did have issue with sending `C-c` (to terminate a process) to it - `C-c C-c` should work, but for some reason didn't.

Yeah, the M-x shell is the one I have problems with. It really is glitchy on all my linux machines. Don't know why. I'm gonna try eshell to see :)

I've seen someone suggested vterm. It's probably the best bet to try first. I haven't tried it myself yet, but see people suggesting it constantly.

I'm unable to install multi-vterm/vterm-mukti from melpa/elpa are you able to?

Vterm still kinda feels janky but better then the others

Vterm is definitely the best of the options. I work with c# and react a lot and I typically have three vterms open- api, auth server, and react site. I use buffer renaming to make them have a good name, instead of just vterm vterm2 vterm3

Just a few things - a terminal emulator and a shell are different things - Emacs has a lot of ways to run shell commands (`M-x async-shell-command`, `M-x compile`, `eshell`, `detached.el`, `pueue.el` etc) - If you want a terminal emulation in Emacs, there are also a couple of options, like `ansi-term` and `vterm` (and related ones). But to be fair, I can't remember when was the last time I needed terminal emulation.

> It really is glitchy what are you trying to run there?

Just as an alternative to the suggested emacs shells: a tiling window manager + emacsclient is also an interesting way to handle the shell/emacs switch pretty efficiently.

Yeah! I tried Terminator and used emacs -no-window on my left side and Ipython on my right side. Worked pretty well and I really loved it. But the copy-paste cannot really be transfered from one window to the other unfortunately. Would be perfect otherwise.

M-x shell is fantastic, if you use it as a shell. M-x shell is bad if you try to use it as a terminal because it's not a terminal; it's a completely different thing. vterm can be good if you need a full terminal but it's clunky if all you need is a shell.

The best thing about eshell is you can extend it using elisp, and you don't have to use a janky awful language like bash or zsh. The worst thing about eshell is if you've already spent a lot of time customizing bash or zsh, you have to start from scratch.

What is the nature of the glitchiness? I use (term "/usr/bin/fish") and it isn't janky in the least. Everything works perfectly, just like it was run in a real terminal. I have a hard time understanding what people are doing in their shells that isn't working. Shell and eshell are janky elisp programs, not real shells. But term is just your shell. Vterm is the same. The latter is supposed to have better performance and capabilities, but I have never noticed a difference.

When I use M-X shell inside emacs, there are random useless text line that pops out into the shell whenever I press enter or another key. Which seems like a funny behavior haha

It may take a little while for most people to realize it, however, M-x shell is a great shell environment and it is not a great terminal. You could think of it as a dumb terminal that has an infinite amount of lines and you can use regular Emacs to edit anything in those lines. This can be super useful. However, you cannot run applications that need a finite terminal with special abilities, so for those applications vterm could be good.

I run eshell inside emacs. It does all the basics I need, and rarely do I need to use the non-eshell terminal emulator

Elisp is itself kinda janky tho lmao

> X11 came out in 1812 Idk if this is a joke or typo but I appreciate it wither way :)

Yeah! I have i3wm pretty tightly integrated with an Emacs daemon/client setup and for me Emacs really sings this way.

Vterm is really close but not quite there for me. I'm still trying to figure out how to make it play nice with evil movement.

> term is bad, ansi-term was "okay" but still really glitchy term and ansi-term are the same thing (not that you gave either a glowing report :) but still...)

I second vterm. Install it via melpa. ansi-term (M-x ansi-term) is okay, but vterm is great.

What I do is just a small function in my config.org to name the shell buffer. If you do that you can open multiple vterm shells and just switch between them

(defun my/zsh-vterm-shell (buffer-name) "Start an interactive shell and rename the buffer" (interactive "sbuffer name: ") (vterm "/bin/zsh") (rename-buffer (format "%s%s%s" "***vterm:" buffer-name "***") t))

well yes but there was this multi-vterm package that did this before

I have been using GUI Emacs + vterm + vterm-toggle, and of course, EDITOR is set to emacsclient. I find vterm to be much better than M-x shell, since the default keybindings are just the same as if it is in other terminals. And ocassionlly I do need to run htop or other terminal-ui programs and vterm is pretty much problem free. I did tried running another `emacs -nw` inside vterm, although I would not recommend you to try -- literally that is a difficult escape room to be in, So for editing remote files, it would still be in-terminal emacs, in that case I mostly hit C-z to suspend emacs when I need to run some commands.

I think I ran into the same issue that you did in that I couldn't install/get it working. Then came across blog that mentioned if you just rename vterm buffer you essentially get the same functionality

Compared to many things, yes, but compared to bash it's a pristine marvel.

For the first, what is your workflow? What are you using the terminal for? If you need to copy output from a shell command, have you tried executing a 'shell-command', bound to M-!, or 'async-shell-command', bound to M-&? The output is automatically place in an ordinary Emacs buffer, named \*Shell Command Output\*, in which you can cut, copy, paste, rename it, save, run any ordinary Emacs commands in, search, replace etc, save it. Are you a student or a hobbyist learning programming, writing a lot of small programs, running them in terminal? Learn how to write simple Makefile and use 'compile' command. Your need to copy-paste between terminal and the editor can drastically reduce. Anyway, if you still need to copy-paste a lot in terminal, try built-in term or ansi-term, you can switch between "character" and "line" modes. In "line-mode" it behaves more like an ordinary Emacs buffer in regard to cursor motion, copy-paste etc, while in character-mode which is default, it behaves more like an ordinary terminal. To be precise, line-mode is more like shell-mode, but you were interested in easier copy-paste, so I suggest you explore line-mode and bind 'term-line-mode' and 'term-chacarter-mode' commands to something you can easily remember. Don't listen to anyone when that say this or that is bad. I suggest you try term or ansi-term first. Ansi-term is supposed to be a slight enhancement of term, but to be honest I myself don't know what is the difference. I don't say you should not use libvterm ever. If you really have an application you often use that does not run well in term or ansi-term, it might be worth the trouble of a compiled module, but I would first test if a built-in, easy accessible solution is good enough.

FYI, you can use ipython within an Emacs buffer just set it as your preferred python interpreter.

I currently use vterm with fish as my default shell. You get to retain all the functionality from a regular terminal emulator (stuff like Spotify-tui and even vim/nvim inside vterm work as you’d expect in a regular terminal). But at the same time you can interact with the vterm instance like you would with a regular emacs buffer, making this really to be the most flexible terminal experience I’ve had so far. Note: if you’re using evil, then Ctrl-Z (at least that’s the binding in doom) in normal mode would allow you to enter ‘emacs bindings’ mode and from there you can use anything with its own set of bindings (like vim/Spotify tui) as you would normally

both are valuable. Using terminal in emacs usually you don’t need to do some complex jobs, you can do any complex jobs in emacs. All you need to do in emacs’ shell may be just building programs/installing programs etc. And for that purpose, as other have mentioned, vterm is the most performant one and e shell is the builtin one and the just work out of box (and eshell works in Windows, this is the killer feature of eshell, you can use your familiar shell syntax in windows) And shell into Emacs is also valuable. The tramp mode works but not great. If you want to use eMacs in a remote container, you often still need to use a no-Xwindow emacs installed in the remote server, and it usually works better than tramp mode. And in my experience, I don’t find significant disadvantage of using tty eMacs compared to gui eMacs (gui eMacs is way better of course, but tty eMacs is just okay). Actually I deploy my eMacs at a remote server and I use Termius app in my cellphone to ssh into that server to use orgmode as my agenda manager. As for copy/paste, I think you just need xclip.el to allow you easily copy/paste text within terminal emacs.

He said term, you say shell .... Shell is not terminal. Term and ansi-term are terminal emulators written in Emacs lisp. Shell is not a terminal emulator. > When I use M-X shell inside emacs, there are random useless text line that pops out into the shell whenever I press enter or another key. What random lines? Where do they come from? There are no random lines in my Emacs with M-x shell. Have your tried with Emacs -Q? Sounds like your setup most likely.

Tightly integrated?

I partly agree. My only problem with `vterm` is that I use `evil`. Without modifying `vterm` it offers very little integration if you have any sort of custom setup. As a compromise I use `term` which offers many of the same features as `vterm` while still maintaining compatibility with the rest of my configuration.

Consider https://github.com/shaneikennedy/npm.el or https://github.com/mojochao/npm-mode

Oh, as in, different clients go into different workspaces at i3 startup, for instance, ``` exec emacsclient -c -e '(mu4e)' -F '((name . "emacs-email"))' ``` to open the Emacs email client, and then ``` assign [class="Emacs" title="emacs-email"] $ws2 ``` for the email client opened with the name ```emacs-email``` to go into Workspace 2, which is the email workspace. This way I can switch between clients dedicated to email, file management, editing, Org Agenda etc. by switching between workspaces. This feels more convenient to me because I can keep them conceptually and functionally separate, even while they all "talk" to each other through the same daemon and buffer history. (Edited for missing word.)

I see. I considered doing that, but I didn't want to bother with it, as I only have a few instances open at a time anyways.

Yeah makes sense, if you only have a few open at a time it's probably not worth the trouble. I open *six* Emacs clients by default so for me it was necessary back when I had to restart X every day because of some memory leak thing. These days the leak is gone and I only restart X once every few weeks for bugs or crashes, so opening the clients manually isn't too much trouble since they'll last me a while.

There are random text lines that appear, especially while I use Ipython inside M-x shell in Emacs GUI (I code in Python modt of the time). Can't explain why. I didn't know there was a difference between terminal and shell. I just learned that, haha. Somebody suggested I run Ipython as interpreter in an Emacs GUI window. And that might be the best solution so far.

This was the best and simplest answer so far. Thank you

I change my post the explain my workflow better :)

Dont use emacs shell. Use vterm instead. Maybe I am misunderstanding you, but why are you copy pasting python code when you can just reload it and run it in the interpreter.

Sometime I run several smaller parts of the code to check how variables change and stuff, instead of just running all the code again. And sinces it stays in Ipython, I can keep those variables in memory, etc.

I personally just run emacs in a shell, and C-z to send it to background to do my shell stuff and then fg to get back into emacs after :)

Thanks for explaining.

Impressed you stuck with emacs all those years

vterm is objectively the best option if you want to integrate terminal and emacs. Personally I prefer a standalone terminal emulator on the side and write code separately in emacs.

As an alternative to all other suggestions (I use M-x shell myself, and works wonderfully for my limited uses). If you are using the shell *only for IPython* why not use the built in `run-python` command, that will also get you completion and history inside Emacs? This is my setup: (use-package python :ensure nil :mode ("\\.py\\'" . python-mode) :hook (python-mode-hook . (lambda () (setf fill-column 79) (display-fill-column-indicator-mode))) :custom (python-shell-font-lock-enable nil) (python-shell-interpreter "ipython") (python-shell-interpreter-args "--pprint --simple-prompt")) (this is based on use-package, if you have trouble "converting it", let me know).You can search through the input history using M-r, clear only the last output, and other niceties, courtesy of `comint-mode`.

Wow. I didn't even know this existed!

I mostly did C code. In 1990, while at Tandem, they had a tool called cscope. You feed it your C code and it built a database which could be quickly searched to find all the definitions, uses, assignments, etc. So, you could type "dogfoo" and it would give you, for example, all the places where dogfoo was assigned. cscope is now open source. I hooked this up to Emacs and it gave me more than any IDE I have yet seen. I'm trying to get lsp-mode with Ruby to provide the same level of functionality but I don't think I'm going to succeed. I was also a consultant so I would move around a lot and it didn't matter what system I was plopped on, if I could get emacs up and running with my init files, I was "at home" with directories, email, news, etc. Remember this is way back in the early 1990s. Yet, I'm still probably more competent at vi than 90% of people who use vi. I'm also competent in ed (not ex). ed was the tiny editor on boot volumes in BSD so if your system wouldn't boot, the only tool you had was ed. I started with "Gosling's" Emacs (which became CCA) and switch to GNU's virtually the day it came out. My mentor (and also ex-student of mine) was from MIT's AI lab so personally new James Gosling as well as RMS.

Running GUI emacs and tmux in a vterm is my favorite way to go. Tmux helps because emacs will crash every so often.

It is a typo - it came out in 1218.

Mostly term is slow. Give vterm a go - you'll notice.

I hadn't really heard about vterm before this post. I swapped term for vterm and it works great. Nice and snappy, as you say. Thanks for the tip!

You'll enjoy [https://www.masteringemacs.org/article/shell-comint-secrets-history-commands](https://www.masteringemacs.org/article/shell-comint-secrets-history-commands) then :)

I'm jumping into the rabbit hole

You're really up on your history!

> personally new James Gosling as well as RMS. When reading RMS on Emacs history and Gossling, there is a slightly different interpretation of events. Whom do you think is more acurate to what happened? Gosslings story about Emacs is here: https://www.reddit.com/r/programming/comments/dhrcxw/james_gosling_on_how_richard_stallman_stole_his/ RMS here: https://www.reddit.com/r/emacs/comments/ios6y5/rms_clarifies_a_point_about_emacss_history/ Not that it matters, as Gossling says, Emacs got a life on its own, and rest is a history, but kind of fun facts.

(Note: my friend knew Gosling and Stallman... I didn't know them.) From what I know, I would assume Gosling's story is accurate although I did notice what I would consider some odd body language when he was telling the story and the idea that RMS took "all the code" doesn't jive with my memory. This was the days of [usenet](https://en.wikipedia.org/wiki/Usenet) and I don't recall how I got my copy of GNU emacs but I assume it was from usenet. We had DEC Vax systems at the time but I never knew DEC and IBM were involved with any of this. And, the little I've surfed around this morning, I can't find anything about a lawsuit except the Wikipedia page saying that no lawsuit was filed. From what I recall, GNU Emacs came out. People noticed that display.c had come from Gosling's version. RMS rewrote it over the weekend and that is the last I heard about any type of copyright problems. All of that, if my memory is correct, was very quick. It seems like a few weeks but perhaps it was a few months. The big thing about display.c was how it optimized the screen update. This was the days of modems (thus usenet) and I believe 1200 baud modems were more or less the "standard" at the time. And, indeed, terminals spread across the campus were limited to something below 9600 baud if it was a long ways off. So screen updates were very slow. Curses ([libcurses](https://en.wikipedia.org/wiki/Curses_(programming_library))) for the most part failed at this optimization. Gosling's did a good job. RMS' rewritten version did a spectacular job. (Off topic but this was a MAJOR problem for me using vi. vi didn't use curses but its implementation was very similar to curses in the lack of optimizations. This leads off into an infinite story of TERMCAP and tweaking your entry so that it could leverage all of Emacs's capabilities ... I'll stop here on this tangent). Also, Gosling's lisp implementation was called "moclisp" and in his documentation scoffed at calling it "lisp". Stallman's Emacs, as far as I recall, re-implemented the lisp engine before the initial release. The story Gosling told I would say is true in the sense that, yes, there was at least one piece of code that was not touched or changed -- display.c. RMS got called on it and he rewrote it easily within the first year and I think way quicker than that. As far as the two guys that bought Gosling's version and was selling it, "called Unipress"... yea. That jives with what I recall but eventually Gosling's version was sold to "CCA" (I don't recall what CCA stood for). So I don't think Unipress suffered much financial loss from the copyright infringement. I just don't see how giving the timing of things.