Emacs opens files in a new frame when opened with "open -a"

8,444

Answer is here: emacs variable to "open with" in original frame

It's a change to the default settings in newer versions of emacs. Add:

(setq ns-pop-up-frames nil)

to .emacs file.

Very happy to have found this.

Share:
8,444

Related videos on Youtube

michiakig
Author by

michiakig

Updated on September 18, 2022

Comments

  • michiakig
    michiakig over 1 year

    I want to be able to invoke Emacs from the command-line, and either start graphical Emacs if it isn't running or visit a file in an already running Emacs. I tried to do this with emacsclient which I know is the "right" way to do this, but I had a lot of problems with it on OS X, it would randomly crash, or the emacs --daemon process would hang during shut down or rebooting the machine, and general flakiness. While I'd like to get that to work, at the moment open -a actually works much better, except for this one problem I'll describe below:

    Using open -a like this:

    $ open -a Emacs file.txt
    

    will start Emacs if it's not running, and visit the file. But if I do this when the current buffer isn't *scratch* the file is opened in a new frame (ie a new system window).

    Here's an example session:

    $ open -a Emacs file.txt
    

    This starts Emacs and opens file.txt, so there's a single frame with this buffer in it. If I switch to the *scratch* buffer, and do this:

    $ open -a Emacs file1.txt
    

    It opens this file in the same frame. Now there's a single frame with this file open, and if I do this:

    $ open -a Emacs file2.txt 
    

    It opens a new frame, resulting in two frames open at once.

    I've tried fiddling with command-line args to Emacs using the --args switch to open, but this doesn't seem to work for subsequent calls, for instance:

    $ open -a Emacs --args --eval='(print "foo")'
    $ open -a Emacs --args --eval='(print "bar")'
    

    This only prints "foo" in the message buffer... the second time Emacs is just brought to the foreground but no message is printed.

    I'm not sure how open communicates with applications that are already running, does anyone know how I could find out? Or is there some way to get a much more detailed log of what's going on than the Messages buffer? Nothing interesting is printed to that buffer during the session above, so I don't know how I could hack some Emacs Lisp to do what I want...

    Thanks!

    • Joe Casadonte
      Joe Casadonte almost 13 years
      I don't know a thing about OSX so I can't provide anything concrete. If I were to debug this, though, I would throw some syntax error into find-file and then set debug-on-error to t and check out the stack trace for some clue as to how Emacs is being invoked. Adding an error to find-file could be as simple as copying the function definition to the lisp scratch buffer and adding a call to error in it (e.g. (error "cause stack trace"). NEVER CHANGE THE SOURCE FILE FOR find-file -- always do this in a scratch bufer!
    • michiakig
      michiakig almost 13 years
      @Joe Thanks! That's a pretty good idea, I'll keep it in mind for the future. I actually ended up trying to use emacsclient again, and starting it with (server-start) in my init.el seems to be working better than emacs --daemon at boot up, which is what I had been trying the first time I tried emacsclient.
  • Dror
    Dror over 11 years
    This was very helpful! Together with an alias open -a /Applications/Emacs.app $1 things seems to work fine! Note that I start the server in my init, to have emacs available for git for example.