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: Perhaps customizing jit-lock could improve fontification over a network.

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.

emacsclient start fails, can't find socket (console or X)

My /dev/shm is empty

I forget you probably need to set an empty $ALTERNATE_EDITOR in the environment where you call emacsclient -c -n - that should auto start a server if it can't find an existing socket.

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.

I always build a Lucid / Athena version. GTK3 has well known bug; it fails immediately on switch between console & X.

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?

-a option starts it. Now the hard part; will it help? Thanks. Stay tuned.

Got it all working. Several minutes later... failure. All strings in a bash script were "highlighted" as black-on-black while in console. All just as I describe in original posting.

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)?

At this point it is probably worth a screenshot or two (and maybe a snippet or so of your ~/.emacs.d/init.el, if any) for anyone here to help understand what you're experiencing

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.

Attached is a screenshot of .bashrc file edited in emacsclient. 0.jpg = normal; 1.jpg = after syntax highlight fails on strings; init.el.

The misbehavior here is in xterm; but, the identical error happens in console, too!

Attached Thumbnails

   

Attached Files

init.el.txt (8.3 KB, 5 views)

Thanks - that does look odd indeed. I take your xterm doesn't have any custom color resources other than the defaults?

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.)

It's certainly not xterm since it occurs just as frequently in a console. But, your comment about frequent switching seems apropos. If I remain in a single instance of emacsclient, there are no problems (so far). Maybe it's a termcap flaw? I use the "Linux" entry from all available.

And, it would useful if someone else could see this errant phenom, too!