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

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Sat, 21 Feb 2015 11:12:44 +0000

 >> Now, given that there’s a number of “internal” functions (such as
 >> ‘internal-lisp-face-p’, for instance) which accept string face names
 >> just fine, I wonder if it makes sense to just change
 >> ‘internal-get-lisp-face-attribute’ accordingly?  An untested patch
 >> is hereby MIMEd.

 > I don't think internal functions should cater to UI issues, unless
 > they are themselves interactive.

        I’m unsure where you see an UI issue here?  The issue, as
        originally reported, is that face-attribute fails to handle
        string-named faces, which are considered perfectly valid by the
        rest of Emacs (including, say, facep and the display engine.)

        That is: the user accidentally sets 'face to a string, and is
        surprised to find that while the result is displayed just fine,
        some part of Emacs (namely, enriched-mode) breaks instantly.

        From there, we can go different ways, including:

        • bury our head in the sand and pretend there’s no issue;

        • patch one or two of the functions which can be used to add
          such faces – to either silently (or not so) replace them with
          the respective symbol-named ones, /or/ to signal an error;
          this won’t prevent, however, the use of put-text-property and
          the likes of it to achieve that same effect;

        • begin to slowly deprecate string-named faces; I guess we’d
          rather have the display engine log the cases of their use,
          at least once per buffer, to highlight the affected code and
          thus ease the migration – from this undocumented feature to
          the documented lack thereof;

        • accept string-named faces as valid and make sure that this
          applies uniformly throughout the code; my latest patch changes
          internal-get-lisp-face-attribute to achieve this, but I’m fine
          with applying an earlier one instead, which similarly changes
          face-attribute.

 > If we keep this confined to interactive functions, how many such
 > functions in facemenu.el will have to be changed?  If not too many,
 > I'm inclined to keep this there.

        I believe that facemenu-add-face is the only function which can
        be used to add a string-named face /interactively/, as it reads
        an arbitrary Lisp form for the face.  (See also #18369.)

        The original report, however, was concerned with the use of
        facemenu-add-face from Lisp, and there’re still a plenty of ways
        to hit this issue apart from using facemenu-add-face with a
        string argument.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A