prettify-symbols-mode breaks SLIME REPL coloring

[TeMPOraL]

It seems that activating prettify-symbols-mode (Emacs builtin) breaks fontification in SLIME. It also has the consequence of completely breaking the in-REPL coloring and clickable areas introduced with log4slime from log4cl project.

Steps to reproduce:

• Open Emacs (e.g. with -Q for clear config).
• Ensure SLIME is loaded with (slime-setup '(slime-fancy))
• Open SLIME with M-x slime
• Activate prettify-symbols-mode with M-x prettify-symbols-mode
• Colors in SLIME REPL should disappear, and will no longer appear until prettify-symbols is disabled and SLIME is ,quit and reopened.

Version info:

• GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21) of 2017-09-22, modified by Debian
• slime-20171207.1712
• Ubuntu 17.10

[ghollisjr]

I can confirm this bug is still active. Some clues I've found:

• SLIME uses add-text-properties and font-lock-keyword-face to colorize the REPL (slime-repl.el: 589)
• prettify-symbols-mode uses font-lock-remove-keywords to clear highlighting (prog-mode.el: 217)
• Before running prettify-symbols-mode: (text-properties-at 1 (get-buffer "*slime-repl sbcl*")) ==> (fontified t field output inhibit-line-move-field-capture t front-sticky (read-only) rear-nonsticky t slime-repl-prompt t read-only t face slime-repl-prompt-face)
• After running prettify-symbols-mode: (text-properties-at 1 (get-buffer "*slime-repl sbcl*")) ==> (fontified t field output inhibit-line-move-field-capture t front-sticky (read-only) rear-nonsticky t slime-repl-prompt t read-only t)

So it clearly looks like prettify-symbols-mode is failing to set the face property for some reason. I don't yet know enough to say whether this is something SLIME needs to address or if it's an upstream bug in prettify-symbols-mode.

[ghollisjr]

More clues:

• slime-repl-insert-prompt is still trying to set the face text property when prettify-symbols-mode is enabled, but it apparently fails somehow as that property is never added to the text properties for the prompt.
• If I manually try to add (face slime-repl-prompt-face) to the text properties, this also fails: (progn (setq inhibit-read-only t) (add-text-properties 1 8 '(face slime-repl-prompt-face) (get-buffer "*slime-repl sbcl*")) (text-properties-at 1 (get-buffer "*slime-repl sbcl*"))) ==> (field output inhibit-line-move-field-capture t front-sticky (read-only) rear-nonsticky t slime-repl-prompt t fontified t)
• However, other properties can still be set: (progn (setq inhibit-read-only t) (add-text-properties 1 8 '(test nil) (get-buffer "*slime-repl sbcl*")) (text-properties-at 1 (get-buffer "*slime-repl sbcl*"))) ==> (test nil field output inhibit-line-move-field-capture t front-sticky (read-only) rear-nonsticky t slime-repl-prompt t fontified t)

So it looks like prettify-symbols-mode is prohibiting the face text property.

[ghollisjr]

Another clue:

• lisp-mode still has colors applied due to the face font-lock-keyword-face property when prettify-symbols-mode is enabled.

Looks like it's confirmed to be a problem with SLIME, at least something that SLIME could address if it's ultimately a bug in prettify-symbols-mode behavior.

[ghollisjr]

Found a fix:

• Setting font-lock-face as well as face solves this issue for non-font-lock and font-lock modes.

I'll post a PR ASAP.

[ghollisjr]

PR #717 fixes this

[ghollisjr]

I did find a blemish in the way prettify-symbols-mode (really font-lock-mode) works with the slime REPL: Any time a " or | character is sent as output, it screws up the syntax highlighting. E.g.:

(format t "Colors are fine | Colors are screwy~%")

will cause everything in the REPL to have string/output coloring until you type/print another | symbol. The way I fixed this for myself is adding this to ~/.emacs as the slime-repl-mode-hook:

(add-hook 'slime-repl-mode-hook '(lambda () (prettify-symbols-mode 1) (set-syntax-table (make-syntax-table lisp-mode-syntax-table)) (modify-syntax-entry ?\" "w") (modify-syntax-entry ?| "w") ))

This modifies the syntax table for the slime REPL so that " and | are ignored for highlighting purposes. It's not ideal, but I couldn't figure out a way to generally fix the problem since the font-lock-mode is using the lisp-mode highlighting functions, which assume that the whole buffer is just one big Lisp source code file. I did notice that for some reason the result output still retains its coloring, so there might be a better hack/workaround still.