Emacsclient Instability Woes
by rdsherman from LinuxQuestions.org on (#5P3NM)
I have been using the latest emacs (27.2) as a server for a few months & encountered repeated sporadic annoyances. What follows is somewhat vague because I cannot give a precise repeatable sequence of operations which lead to a particular fault. Nevertheless, what I describe has occurred on dozens of instances. Few emacsclient sessions are seamless.
On boot, emacs --daemon is launched. All subsequent usage involves emacsclient only, mostly in a terminal (-t switch), sometimes in new frame (-c switch). Initially everything behaves as advertised in console & X. Then on time scales ranging from minutes to hours with various emacsclients in use doing all sorts of operations that made emacs famous, two nuisances inevitably appear:
1) A buffer has a bash or elisp script with font-lock-mode enabled (syntax highlighting). It looks just fine. Then, I switch to another buffer & when I return, part of the file is not visible. Close inspection shows that only text encoded as strings is rendered black-on-black or white-on-white. Disabling font-lock-mode shows nothing is missing! Again enabling font-lock-mode & the same text is missing. Killing the buffer & reloading does not fix the problem. At this point opening any new bash or elisp file with strings is futile. The only way to correct all is a restart of the daemon! Of course, any setup of screens / consoles is lost. However, no data is ever lost or damaged.
2) All is humming along just as it should. I invoke yet another emacsclient & am greeted by error messages notifying that no valid server socket can be found. Checking htop or ps says the daemon is up & running. And /run/user/UID/emacs/server socket is where it should be. Again, only escape route is a reboot of the emacs daemon.
Either one of the above can occur first.
Has anyone else seen these aberrations?
On boot, emacs --daemon is launched. All subsequent usage involves emacsclient only, mostly in a terminal (-t switch), sometimes in new frame (-c switch). Initially everything behaves as advertised in console & X. Then on time scales ranging from minutes to hours with various emacsclients in use doing all sorts of operations that made emacs famous, two nuisances inevitably appear:
1) A buffer has a bash or elisp script with font-lock-mode enabled (syntax highlighting). It looks just fine. Then, I switch to another buffer & when I return, part of the file is not visible. Close inspection shows that only text encoded as strings is rendered black-on-black or white-on-white. Disabling font-lock-mode shows nothing is missing! Again enabling font-lock-mode & the same text is missing. Killing the buffer & reloading does not fix the problem. At this point opening any new bash or elisp file with strings is futile. The only way to correct all is a restart of the daemon! Of course, any setup of screens / consoles is lost. However, no data is ever lost or damaged.
2) All is humming along just as it should. I invoke yet another emacsclient & am greeted by error messages notifying that no valid server socket can be found. Checking htop or ps says the daemon is up & running. And /run/user/UID/emacs/server socket is where it should be. Again, only escape route is a reboot of the emacs daemon.
Either one of the above can occur first.
Has anyone else seen these aberrations?