Emacsclient Instability Woes
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? |
I'm interested in emacs, and I tried its http server before, and was impressed -- it was easier to authenticate a user than with hunchentoot / hunchentoot auth. But I wasn't connecting emacs clients to it, I was connecting web browsers... so many modes--someone's made a mode to control vibrators--
I do remember reading this, which seems relevant from the info-emacs-manual: Quote:
|
Thanks "slac-in-the-box".
But, this easily occurs on tiny files, just a kB is enough. |
Have you tried starting the daemon not with emacs --daemon but with emacsclient -c -n? I found there are nuances between these ways of starting the server that could affect where your server socket location is, for example.
Another thing you might watch out for is if your /dev/shm is piling up - Emacs likes to make a lot of tempfiles (or backups of vc buffers) over time and if you're only rebooting the daemon and not cleaning up /dev/shm, that might affect your setup. |
Quote:
My /dev/shm is empty |
Quote:
Good to know your /dev/shm is empty - it should normally be for most use cases. |
I made a point of using emacsclient instead of just plain emacs last night while working on one of my projects. I didn't notice anything untoward — though for full disclosure, I do rebuild emacs with the lucid widgets rather than using gtk.
|
Quote:
As I noted in my original post, it's sporadic. Can take minutes to hours to days for problems to appear. That is what makes this hard to solve. I'll ask another question as a paraphrase of all. Can anyone find a key chord combo that might induce the syntax highlight failure on strings only? |
Quote:
|
Quote:
I'll ask my initial question this way: What kind of fault could cause font-lock-mode to syntax highlight all words properly except one (strings)? |
Quote:
Are you also experiencing this on a running daemon without any ~/.emacs.d customizations (e.g. emacs -Q --daemon ?) If you can and experience no font-lock weirdness on strings anymore (you can speed it up via M-x font-lock-debug-fontify on buffers,) I'd suggest slowly reintegrate pieces of your customizations until you find what's breaking it. |
3 Attachment(s)
Quote:
The misbehavior here is in xterm; but, the identical error happens in console, too! |
Quote:
I've seen a similar issue but that one is between Emacs under xterm vs GTK (or on iTerm2 vs NS/Cocoa on macOS,) where when you start the daemon on either xterm or headless (e.g. plain emacs --daemon without using (server-start) in your config) and frequently switching/calling Emacs frames across console/xterm/GUI. The xterm/GUI difference stems from certain xterms not having 256 color support - in my case, that was easily resolved by using a modern xterm like kitty. Not sure if this would work on your case though, since you mention using Emacs on the console (which IIRC only supports 8.) |
Quote:
And, it would useful if someone else could see this errant phenom, too! |
All times are GMT -5. The time now is 08:16 PM. |