Whatever your .emacs and its improvements, you also should consider running emacs as a server at your session's opening :
Now, running emacs with
emacsclient -nw -c
or ... (see options) will be much faster
I needed to manage the desktop files just like you; have a separate desktop file for each project and save buffers, Emacs variables, etc independently for each.
I was able to achieve that using a package called bookmark+.
Library Bookmark+ manages different types of bookmarks, one of those is Desktop Bookmarks.
After installing the package,
1) I have found esup to be a very convenient for Emacs startup profiling.
You just run M-x esup and get back list of all expressions in your init.el sorted by the time they took to execute. You don't need to restart Emacs or add anything special to the config, so narrowing on the slow down suspect becomes much easier.
2) I (use-package :defer t) all the ...
You can save the buffer-local value of comint-input-ring in a global variable when an *ielm* buffer is killed and restore it in inferior-emacs-lisp-mode-hook:
;; global copy of the buffer-local variable
(defvar ielm-comint-input-ring nil)
(defun set-ielm-comint-input-ring ()
;; create a buffer-local binding of kill-buffer-hook
Using (setq desktop-path (list my-desktop-dir)) before calling (desktop-save-mode 1) seems to solve the issue:
(setq desktop-path (list "~/emacs-server"))
Note: You will now get a question Save desktop? (y or n) when killing Emacs server and this is the first time you save the desktop..
IIUC buffer-undo-list is missing from buffer-local-variables by accident. The accident is that some code clean up ended up making buffer-local-variables use the same loop over some of the buffer's local variables, as the loop used when the garbage collector looks for references in a buffer object.
As it turns out, buffer-undo-list needs to be handled ...
Building on the accepted answer, this two line solution loads for me without a locked prompt.
(setq desktop-load-locked-desktop t)
(call-interactively 'desktop-read t (vector "~/.emacs.d/desktops/" t))
You can check if the process is still alive using system command ps -p $PID, then delete the lock file if the process is not still alive. The following modification of init2.el above shows how this can be done from within Emacs. Note that I use two private functions from desktop.el, namely desktop-owner and desktop-full-lock-name.
I have the following in my equivalent of a .emacs file:
(defun my-bury-star-buffers ()
"Bury all star buffers."
(mapc (lambda (buf)
(when (string-match-p "\\`\\*.*\\*\\'" (buffer-name buf))
(add-hook 'desktop-after-read-hook #'my-bury-star-buffers)
I don't remember where ...
Side note, it is generally considered a good idea to have your startup code in ~/.emacs.d/init.el rather than ~/.emacs, one less hiden file in your home directory, a suffix so that other editors can guess the contents....
For bisection, the idea is that you stop running your .emacs about half way and see if it still takes a lot of time. If it does then you ...
My answer at https://stackoverflow.com/a/4485083/324105 might be of interest (even though this is almost the opposite to what you actually asked for).
With the custom my-desktop command, I only load my desktop file when I want to do that. Once loaded, I do automatically save it (but to my mind, if I loaded a desktop file, why wouldn't I want to save it?)
I believe you can achieve this by setting desktop-file-name-format to "local".
Here's what describe-variable says about it:
desktop-file-name-format is a variable defined in `desktop.el'.
Its value is absolute
Format in which desktop file names should be saved.
Possible values are:
absolute -- Absolute file name.
tilde -- Relative ...
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 ...
In order for desktop-read (the function used to restore your desktop from a file) to restore the frameset that was saved in the desktop, it must call desktop-restoring-frameset-p (i.e., "should I restore the saved frameset?"), which in turn checks the function display-graphic-p (i.e., "is this a GUI or a TTY?"). This essentially means that, even though ...
There's a hook you can use: desktop-after-read-hook. Add a function to set a variable after the desktop state is restored. Using defadvice around desktop-save, check if the variable is set before saving the state.
I'm on Emacs 25.3.1, and this is the code I used:
(defvar *my-desktop-save* nil
"Should I save the desktop when Emacs is shutting down?")
There's special-event-map which can be used to handle signals among other things, you can bind a key like [sigusr2] there to a function you'd like to be executed on the respective signal. I'm not so sure whether it works on anything else than SIGUSR1 and SIGUSR2 though.
edit: Here's an useful example of how one could use it:
Ordinarily, one would use a
to repeat a task at given time intervals. However, the manual
node on Saving Emacs
When desktop-save-mode is active and the desktop file exists,
Emacs auto-saves it every desktop-auto-save-timeout seconds,
if that is non-nil and non-zero.
I found this information by looking in the elisp manual ...
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 suspect you have unremoved desktop lockfiles, which will usually be in your config dir/folder, which is hopefully ~/.emacs.d/. Here's a procedure for testing my hypothesis from a commandline (e.g. a Bash shell running in a terminal app under Linux):
Ensure you have no emacs* processes running: i.e., there should be null response to
pgrep -l emacs
If you ...
You can't usefully have two simultaneous Emacs session that use the same file to store the session state. Each time a session saves its state, it would overwrite the other session's state.
Many people run a single Emacs session. To open a file in the existing Emacs session, use emacsclient (see also the Emacs wiki). Emacsclient has several options to ...
You can try https://www.emacswiki.org/emacs/MidnightMode -- by default this will cleanup old buffers once a night.
To reduce the delay time on opening emacs with a lot of saved desktop buffers, you can modify desktop-restore-eager - set it to a low number and only those will be opened immediately, with the rest being opened lazily.
In the desktop file I found I had another TeX file in my saved session whose TeX-master file was a.tex. Closing that file solved the issue.
Perhaps auctex or some other TeX-mode was opening a.tex whenever the other file was opened at startup when restoring the saved session?
I found it. Apparently dired can't access icloud directories. My Desktop and Documents folders are sync'ed with icloud.
If anyone comes here curious as to how they can access Desktop, Documents, or Downloads, the answer is in the link above, for reference, but ...
You are passing a literal list as the second arg to setq. Instead, you want to substitute the value of the (car...) sexp.
You can do that using a backquote construction, telling it to evaluate that (car...) sexp and use the result of the evaluation.
You want this:
(setq frame-title-format `("%b Desktop: "
,(car (last (split-...
I like the question, and I agree with its suggestion.
I don't think there is any good reason why desktop.el accepts only a directory (folder) argument and not, alternatively or additionally, a file argument for desktop-read.
After all, that function is about reading a desktop file. Why make it impossible to pass a file to the function? Why make the ...
I believe a directory was used primarily because more than one file is saved there.
As well as the desktop file itself (desktop-base-file-name) there is also a lock file (desktop-base-lock-name).
Those are just variables, so there's nothing stopping you from writing a custom command to read a desktop-base-file-name from the user, derive an appropriate ...
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.
You should be able to set desktop-dirname to the directory of your choice and then every time you save using desktop-save-in-desktop-dir it will save in that directory. You can still use desktop-save and it will provide you with the usual home directory prompt.