-
-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] desktop.el and org-roam-ui-mode: Cannot bind server socket: Address already in use #202
Comments
Probably even better patch is not to save
|
Org-roam-ui should make it easy to configure port & host (expose to your local network by binding to |
I don't think that is relevant to this issue. Even if I would set some different port, I believe that the issue is still the same - org-roam-ui tries to bind to that port multiple times, failing after the first try. |
I'm having this issue but also org-roam-ui is not following me despite follow mode being enabled. I disabled desktop saving and having the same issue, both the socket issue and the no-follow issue. |
Describe the bug
When using desktop.el to persist emacs state between sessions, the org-roam-ui-mode causes the loading of the persistent state fail. Each saved buffer has org-roam-ui-mode listed in its minor modes, causing the desktop.el to try to load org-roam-ui-mode for each of them. But all the calls to org-roam-ui-mode (except perhaps for the first one) result in error - "Cannot bind server socket: Address already in use".
To Reproduce
Additional context
Don't known if this is important, but I am using
(setq desktop-restore-eager 10)
, making desktop.el restore 10 buffers immediately and restore the rest of them lazily.Expected behavior
org-roam-ui-mode should fail gratiously (without elisp error, just with a message), when the server socket is already in use. Or maybe even better, it should detect that the socket is actually used by org-roam-ui-mode itself.
** Simple patch for my purposes **
I patched the org-roam-ui-mode to ignore errors. Proper solution would probably still need to let the user know about the issue.
The text was updated successfully, but these errors were encountered: