# Calling emacsclient from ansi-term makes emacsclient hang, how do I get around this?

Sometimes I use ansi-term in emacsclient instead of directly using my shell. When I do this, it is not an infrequent occurrence that I forget where I am and call emacsclient someFile, which freezes the terminal window and doesn't let me start a new emacsclient process. Is there a way to make invocations of emacsclient in ansi-term instead open the file? Or some other way to unfreeze this? The only solution I have found is to kill the server process.

• FYI it's not normal for Emacs to freeze in that scenario. I can happily nest Emacs instances inside term buffers, without issue. Check with emacs -Q (and running emacs -Q -nw in the term buffer). If that works, you could then recursively bisect your config to determine the cause of the problem. – phils Mar 14 '17 at 2:41
• @phils it doesn't freeze when I do that. I think it might be because I am already in a client, and my Emacs is aliased to try to open a new client. – Andrew Mar 14 '17 at 20:09
• That's missing information from your question, then. Please update the text with the appropriate details. It sounds like you're "calling emacsclient" rather than "calling emacs". I suggest eliminating aliases from the equation, and just providing the (unaliased) commands to trigger the issue under emacs -Q ? – phils Mar 14 '17 at 21:38
• I made a hacky way around this - the env variable $EMACS is set if you are in emacs, so I changed my alias for my editor to launch emacsclient only if it isn't set, otherwise fail and print error message. Works so far, would still be interested in a more elegant solution though. – Andrew Mar 15 '17 at 20:12 • Note: this is Bug#22639 – npostavs Jun 13 '17 at 11:12 ## 2 Answers It looks like ansi-term sets the TERM environment variable to eterm, possibly extended to eterm-color or similar. You can use this to define emacs to an appropriate alias whenever you're already in ansi-term inside emacs. Something like this in your .bashrc: case "$TERM" in
eterm*)
alias emacs=emacsclient
;;
*)
## code to run for non-eterm shells
;;
esac


If that doesn't work, another option is the environment variable INSIDE_EMACS, which is set to <emacs version>,term<term version>. Note that shell-mode sets this to <emacs version>,comint, so if you use both you'll want to distinguish between them with your test:

case "$INSIDE_EMACS" in *term*) alias emacs=emacsclient ;; *comint*) ## code to run for shell-mode ;; *) ## code for non-emacs shells esac  • Hmm, when I run echo$TERM in ansi-term I get xterm-256color - this is the same thing I get when run it in a normal shell – Andrew Mar 13 '17 at 21:37
• There isn't much documentation for ansi-term, so I'm mostly guessing based on what I see when I run it on my machine. Try running env from within ansi-term - maybe you'll see a variable there that is different from your regular xterm shell that you can use instead. – Tyler Mar 13 '17 at 21:40
• @Andrew you must have customized term-term-name for that to be true (or set TERM in your .bashrc?). You could also check $INSIDE_EMACS. – npostavs Mar 13 '17 at 22:36 • I believe the INSIDE_EMACS environment variable is the correct way to test for this. Its value can vary (e.g. it will be different between M-x shell and a shell run in M-x term), so you would probably just want to test for [ -n "$INSIDE_EMACS" ] – phils Mar 14 '17 at 2:36

You don't have to display an error when using emacsclient from inside term : you can make it use your current Emacs instance.

For shell-mode, there is a package called "shx", which provides useful shell commands like :e (to edit a file), :diff (to ediff 2 files ), :find (run find command and open files in clickable output) etc.

Edit : and yes, you never need to kill the server process too. On unixes, just send it a USR2 signal and Emacs would drop whatever it was doing and unfreeze from most situations including this one.

" killall -USR2 emacs"