error in process filter; don't know how to interpret display ... org.macosforge.xquartz

[csdrane]

I receive this error any time I try to use the Edit in Emacs plugin.

error in process filter: make-frame: Don't know how to interpret display ""/tmp/launch-IcrLfZ/org.macosforge.xquartz:0""
error in process filter: Don't know how to interpret display ""/tmp/launch-IcrLfZ/org.macosforge.xquartz:0""

[stsquad]

Is this a nested X on Mac or a Native Mac Emacs your using?

[csdrane]

Emacs built through homebrew with --cocoa enabled. I use the terminal version typically though.

[stsquad]

I wonder if this bit is failing:

 (if (memq window-system '(ns mac))
                ;; Aquamacs, Emacs NS, Emacs (experimental) Mac port
                (make-frame edit-server-new-frame-alist)
              (make-frame-on-display (getenv "DISPLAY")
                                     edit-server-new-frame-alist)))

What does window-system report (sorry I don't have access to any Mac's here ;-)

[csdrane]

I don't know exactly what info you're looking for.

(window-system)
> nil
(memq window-system '(ns mac))
> nil
(make-frame-on-display (getenv "DISPLAY")
                                     edit-server-new-frame-alist))
> Debugger entered--Lisp error: (void-variable edit-server-new-frame-alist)
  (make-frame-on-display (getenv "DISPLAY") edit-server-new-frame-alist)
  eval((make-frame-on-display (getenv "DISPLAY") edit-server-new-frame-alist) nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)

Evaluated via C-x C-e in scratch.

[stsquad]

If edit-server-new-frame is nil it shouldn't try and create a new GUI frame and just pop the edit-server buffer to the front of your tty window of Emacs. I suspect the edit-server could do a better job of handling new-frames when DISPLAY is nil though. I'll see if I can re-factor the code a little. In the meantime can you check that state of edit-server-new-frame?

[csdrane]

Apologies, I pasted the wrong error message before. See below.

> (make-frame-on-display (getenv "DISPLAY")
                                     edit-server-new-frame-alist)
Debugger entered--Lisp error: (error "Don't know how to interpret display \"\"/tmp/launch-IcrLfZ/org.macosforge.xquartz:0\"\"")
  signal(error ("Don't know how to interpret display \"\"/tmp/launch-IcrLfZ/org.macosforge.xquartz:0\"\""))
  error("Don't know how to interpret display \"%S\"" "/tmp/launch-IcrLfZ/org.macosforge.xquartz:0")
  make-frame(((display . "/tmp/launch-IcrLfZ/org.macosforge.xquartz:0") (name . "Edit with Emacs FRAME") (width . 80) (height . 25) (minibuffer . t) (menu-bar-lines . t)))
  make-frame-on-display("/tmp/launch-IcrLfZ/org.macosforge.xquartz:0" ((name . "Edit with Emacs FRAME") (width . 80) (height . 25) (minibuffer . t) (menu-bar-lines . t)))
  eval((make-frame-on-display (getenv "DISPLAY") edit-server-new-frame-alist) nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)

[stsquad]

make-frame-on-display is really Linux/X windows only.

[alpha22jp]

Hi @stsquad

I'm the author of Atomic Chrome for Emacs which is similar to Edit with Emacs. This package is very helpful for me to know how to open a new frame and get it focused.

BTW, It appears that the last commit (0a50fbb) breaks the behaviour of opening a new frame. When I start Emacs with emacs --daemon and press the edit button on Chrome, a new frame doesn't popup. I think it's because window-system returns nil while Emacs has no frame.

Am I misunerstanding something? I'm using Emacs 25.1 on Linux (ubuntu 14.04).

[stsquad]

@alpha22jp yeah I think the logic is a little broken. Fundamentally (window-system) reports the current frames display so is a poor test for deciding if we can create a new graphical frame.

[stsquad]

Well it works if there was a graphical window at some point, which is my default, I only enable edit-servers when:

(when (and (getenv "DISPLAY") (daemonp) (not I-am-root))
  (if (locate-library "atomic-chrome")
      (use-package my-atomic-chrome)
    (use-package my-edit-server)))

The failure only occurs if I start an emacs daemon session in a terminal session without display set. However if I create a X frame via emacsclient things work after that. I think we need to delve into the display code to see how emacsclient knows if it can display something on X.

[stsquad]

OK this fix has caused #132 and #133 so we need a decent solution that keeps both use cases happy. It seems the --daemon does not keep window-system set.