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.

  • 2
    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
  • 1
    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
  • 1
    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

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 
         alias emacs=emacsclient
         ## code to run for non-eterm shells

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 
         alias emacs=emacsclient
         ## code to run for shell-mode
         ## code for non-emacs shells
  • 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

See "with-editor" :

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"

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.