bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-enco


From: Ivan Shmakov
Subject: bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode
Date: Fri, 20 Feb 2015 09:12:08 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

>>>>> Jorge  <jorge13515@gmail.com> writes:

[…]

 > However, it seems to me that the current behavior is not
 > user-friendly.  (facemenu-set-face "bold" 1 2) _does_ make the text
 > bold, without any warning – which makes it appear that the call was
 > successful – but then we get an error when we try to save the buffer.

        The facemenu-set-face command is essentially a call to
        facemenu-add-new-face, followed by a call to facemenu-add-face.
        Curiously enough, the former implements explicit support for
        string arguments:

$ git archive --format=tar  c4e2be4587ec -- lisp/facemenu.el \
      | tar -xO | nl -ba ;  # 2015-02-16 07:22:46 +0000 
…
   785  (defun facemenu-add-new-face (face)
   786    "Add FACE (a face) to the Face menu if `facemenu-listed-faces' says 
so.
   787  This is called whenever you create a new face, and at other times."
   788    (let* (name
   789           symbol
…
   792           function menu-val)
   793      (if (symbolp face)
   794          (setq name (symbol-name face)
   795                symbol face)
   796        (setq name face
   797              symbol (intern name)))

 > Generally, it is best for errors to be detected as close to their
 > source as possible.  What do you think?

        If string faces are rendered just the same as symbol ones,
        I’d rather wonder if either facemenu-add-face should silently
        ‘intern’ all the strings it gets before use, /or/ face-attribute
        should do that.  (Or perhaps both.)

-- 
FSF associate member #7257  np. Transformation — David Modica  B6A0 230E 334A





reply via email to

[Prev in Thread] Current Thread [Next in Thread]