bug#1836: emacs -Q -fn "nonexistent" hangs

[Jason Rumney <jasonr@gnu.org>]

Juanma Barranquero wrote:
> Package: emacs
> Version: 23.0.60
> X-Debbugs-CC: monnier@iro.umontreal.ca
>
> [Note: This is *not* bug#1548, which apparently was just fixed by Jason.]
>   

Yes, I haven't yet marked 1548 as fixed, because I came across this, but 
this one seems to exist on GNU/Linux too so I was going to open a 
separate bug report about it before closing 1548.

What seems to be happening is that an error is thrown during frame 
creation ("No fonts match `nonexistent'" - the same error that Emacs 
22.3 produces), but the top-level lisp loop catches this error and 
continues executing the main lisp loop without ever having created a frame.

My guess was either the multi-tty or daemon changes had introduced this, 
your investigations seem to point to the latter.

> +	   /* We used to check if "This is the case of the frame dumped with
> +              Emacs, when we're running under a window system" with
> +	        || (!NILP (Vwindow_system) && !inhibit_window_system
> +	            && FRAME_TERMCAP_P (sf))
> +	      then the multi-tty code generalized this check to
> +	        || FRAME_INITIAL_P (sf)
> +	      but this leads to undesirable behavior in daemon mode where
> +	      we don't want to exit just because we got an error without
> +	      having a frame (bug#1310).
> +	      So I just removed the check, and rely instead on the `message_*'
> +	      functions properly using FRAME_INITIAL_P.  In the worst case
> +	      this should just make Emacs not exit when it should.  *


Do we have a global flag to indicate that Emacs was started in daemon 
mode that we could use here? How do we decide whether to exit when the 
last frame is closed for example?