0

I've been debugging an error when I call htmlfontify-buffer on my *shell* buffer or SLIME.

I found out the problem seems to be a value returned by the face-attribute function that seems to be a cons whose first element is just quote. That gets passed to the hfy-face-to-style-i function which then breaks with error invalid face: quote.

Here's a demonstration of the problematic value:

(face-attribute 'ansi-color-bold :inherit)
'bold

(type-of (face-attribute 'ansi-color-bold :inherit))
cons

(princ (face-attribute 'ansi-color-bold :inherit))
'bold'bold

(car (face-attribute 'ansi-color-bold :inherit))
quote

I don't understand enough elisp to know if this is "ok" and the bug is in the other parts of the code.

Looking with the debugger, I see that this weird value comes into play when hfy-face-attr-for-class is called with the FACE argument with value 'ansi-color-bold...

In the Customization buffer, I see that this face has a List Expression:

((t
  (:inherit 'bold)))

When FACE gets passed into (face-attr-construct face), it returns (:inherit 'bold).

This gets into hfy-face-to-style-i as fn which does:

    (let ((key  (car  fn))
          (val  (cadr fn))

Now, val has the weird value, it runs this:

      (if (eq key :inherit)
        (let ((vs (if (listp val) val (list val))))

As listp val returns t, as the weird value is a cons, now vs has the value 'bold and it goes on to dolist on it:

          (dolist (v vs)
            (setq parent
                  (append
                   parent
                   (hfy-face-to-style-i
                    (hfy-face-attr-for-class v hfy-display-class))))))

In the first iteration, v is just quote. (type-of v) returns symbol.

And that's how quote gets passed to hfy-face-to-style-i which errors out.

So, I belive I have all information to know how to fix the bug, but still can't do it as I fail to understand this one weird cons with quote and symbol bold in it.

Is that a "proper" value? If so, should I edit the dolist call above to handle the quote specially? Or do I need to fix this value being returned by face-attribute in the first place?

EDIT:

I found out that ansi-color-bold is defined like this at /Applications/Emacs.app/Contents/Resources/lisp/ansi-color.el.gz:

(defface ansi-color-bold
  '((t :inherit 'bold))
  "Face used to render bold text."
  :group 'ansi-colors
  :version "28.1")

Is the 'bold incorrectly quoted as @db48x says? I found this file on GitHub here but it does not seem to have a quote... This file seems to be part of my installation, which came from brew.

1

1 Answer 1

1

You just have a typo in your customization of the ansi-color-bold face. Remove the apostrophe and the problem will go away.

The apostrophe tells the Lisp interpreter to quote the next thing that it reads, so '(+ 2 2) evaluates to the list of three things, a symbol + and two 2s while (+ 2 2) evaluates to 4 (because it is a call to the addition function).

Internally this quoting is done by consing the value with the symbol quote. Thus '(+ 2 2) is read as (quote (+ 2 2)) and 'bold is read as (quote bold).

Your problem happens when you use a quote inside of something that is already quoted. Something like '(+ 2 'bold) is read as (quote (+ 2 (quote bold))) (this is a nonsense expression, but it is illustrative).

7
  • @renato You can check the definition added by the customization at the end of your init file. Maybe in the customization buffer, you could just 'Erase the customization' for the face via the 'Revert' button at the top. Jan 22, 2023 at 8:22
  • Sorry if I didn't make it clear, but I do not customize anything. The ansi-color-bold config shows as "STANDARD" in the apropos view. I searched anyway on my custom file and ther's no reference to "bold" anywhere.
    – Renato
    Jan 22, 2023 at 17:34
  • Edited the question to mention that I found the definition of ansi-color-bold and it does have a double-quote, but I can't change that even by calling eval-last-sexp. Seems to be a bug in my distro?
    – Renato
    Jan 22, 2023 at 17:50
  • I fixed the problem now by replacing my distribution's ansi-color.el.gz file (which had several other fonts with the extra quote breaking stuff) with the one I found on GitHub (had to remove the .elc file). Thanks for the hint.
    – Renato
    Jan 22, 2023 at 18:02
  • A quick check of the history of that file shows that this bug was fixed a little over a year ago. Maybe you should just upgrade?
    – db48x
    Jan 22, 2023 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.