Hot answers tagged


Not exactly what you are asking for but maybe a solution to your original problem: I'd like to know if there is a general way to keep emacs --daemon from hanging forever waiting for an answer to a prompt displayed in a minibuffer that doesn't exist yet. If the daemon gives you a graphical frame for answering questions arising in its startup-phase you do ...


The things that I did on the @DoMiNeLa10's advice: Set (add-to-list 'default-frame-alist '(font . "SF Mono-14")) instead of (set-face-attribute 'default nil :font "SF Mono-14") (set-frame-font "SF Mono" nil t) By playing around with evaluating (menu-bar-mode -1), (tool-bar-mode -1) and (scroll-bar-mode -1) I just found out that it works if I remove the ...


Our discussion cleared that you do not have any X-server running this renders my first solution useless for you. In the following I present a second solution that works with text terminal frames. When your initialization requires user input through one the functions advised with avoid-initial-terminal Emacs waits until you open a text terminal frame. The ...


I think defering the prompts is going to be difficult in general, but it should be fairly easy to change Emacs so that such prompts immediately signal an error. Not only that, but if you can't answer those prompts without a lot of gymnastics, I think it qualifies as a bug, so I'd recommend you submit a bug report for that.

Only top voted, non community-wiki answers of a minimum length are eligible