GNU bug report logs - #19903
24.4; Emacs fails to save enriched buffer with error message `wrong-type-argument symbolp "bold"'

Previous Next

Full log

Message #46 received at 19903 <at> debbugs.gnu.org (full text, mbox):

From: Ivan Shmakov <ivan <at> siamics.net>
To: 19903 <at> debbugs.gnu.org
Subject: Re: bug#19903: 24.4;
 wrong-type-argument symbolp "bold" during enriched-encode 
Date: Wed, 25 Feb 2015 06:20:36 +0000

>>>>> Eli Zaretskii <eliz <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.