3

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.

5
  • 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, 2017 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, 2017 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, 2017 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, 2017 at 20:12
  • Note: this is Bug#22639
    – npostavs
    Jun 13, 2017 at 11:12

2 Answers 2

0

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
4
  • 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, 2017 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, 2017 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, 2017 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, 2017 at 2:36
0

See "with-editor" : https://github.com/magit/with-editor/blob/master/README.md

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 agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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