Timeline for Daemon mode: Defer interactive prompts on startup?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 2, 2019 at 19:00 | comment | added | Trey | What? No, I'm talking about the issues. I asked the question because I know Emacs is extensible enough that all these issues might be solvable. If you know Emacs well enough to say, no, they're not, then yes, I'll submit a bug. But what part of this is arguing against fixing? If, upon first connecting with a client after interactions blocked, you were led through answering each of the queued interactions, that would be a 100% solution, not an argument against solving it. | |
| Apr 2, 2019 at 18:54 | comment | added | Stefan | @Trey: I don't understand, you seem to be arguing against fixing the problem. In any case, this is not the place to discuss it. Please M-x report-emacs-bug instead. | |
| Apr 2, 2019 at 18:00 | comment | added | Trey | ... doing this the way I can see to do it would result in three problems: 1) a maximum of one thing could be waiting on minibuffer input; any other attempts wouldn't be queued, they'd just error out; and 2) similarly, anything that tried to write directly to minibuffer rather than just messages would also defer/err, and 3) as you know if you've ever had something early in startup prompt and something later write to the minibuffer before you've answered, the question changes to just Please answer y(es) or n(o) — so, if deferred, you have absolutely no idea what you're saying yes or no to! | |
| Apr 2, 2019 at 17:56 | comment | added | Trey | Oh—also note that yes-or-no-p, alone, is not sufficient—note my example asking about restoring a TRAMP buffer asking for a password. Recently, I've had to kill hung daemons waiting for GPG passphrases and Git SSH key token passphrases, too, then excise the code that was allowing this to happen at startup. Using use-package's helpful :defer flag can fix these when identified—but it also negates the reason to have an autostarting daemon: an Emacs that doesn't have to load stuff. It would be nice to say "defer only on attempt at interaction"—though the plumbing would be difficult since... | |
| Apr 2, 2019 at 17:21 | comment | added | Trey | Stefan—from perusal of the docs and Elisp, I agree your solution seems plausible. But my Elisp is poor (or rather, my ability to use Emacs programmability is poor—my Elisp as a language is fine). If you have the knowledge to add the necessary—hooks? Advice?—here I reach the limits of my understanding of Emacs under the hood, please supply them—and the bounty is yours ;-) | |
| Apr 2, 2019 at 17:16 | comment | added | Trey | In either case, though, most users don't peruse *Messages*—and while the little-used *Warnings* system does pop up a window to the buffer if an active frame exists when the warning is generated, in this case, no frame exists, and it doesn't appear easy to defer the pop-up until the first emacsclient following the warning's issue. If that could be done, your suggestion of making a pre-client yes-or-no-p warn instead would be quite ideal. (I doubt users comb *Messages* on startup!) | |
| Apr 2, 2019 at 17:15 | comment | added | Stefan | @Trey: the error signaling shouldn't be in desktop but in the y-or-n-p function (or lower yet). We have some mechanism to delay displaying errors that happened during startup, so we could use that to display them when the first emacsclient connects to the daemon. | |
| Apr 2, 2019 at 17:11 | comment | added | Trey | (To clarify for those who don't use the daemon—if you start it manually, either via emacs --daemon or by starting emacsclient with the ALTERNATE_EDITOR environment variable set to the empty string, you will see the output that ordinarily goes to *Messages* echoed in the terminal until the daemon completes initialization and Emacs is ready. But many have Emacs start the daemon at system startup or login time, and the output is either logged or thrown away. | |
| Apr 2, 2019 at 17:08 | comment | added | Trey | Stefan, also there's an issue that doesn't bother me because I don't run the Emacs daemon this way, but to make a generally useful answer might need addressing: erroring out fatally will cause Emacs started up via systemd or other watchdogs to restart in a loop. But ignoring errors and just logging to *Messages* is probably insufficient heads-up on first client connect that something may be seriously awry and need immediate attention before the user attempts any stateful operations. | |
| Apr 2, 2019 at 17:05 | comment | added | Trey | I think I need a bit more detail. Consider the desktop save-file lock I mention in the comment to the bounty above. How would one go about changing the Warning: desktop file appears to be in use by PID xxx. Using it may cause conflicts. Use it anyway? (y or n) prompt into an error, without specifically referring to "desktop" in some way (because that way, being nongeneral, lies whack-a-mole)? | |
| Apr 2, 2019 at 14:03 | history | answered | Stefan | CC BY-SA 4.0 |