From: Ivan Shmakov <ivan@siamics.net>
To: 19903@debbugs.gnu.org
Subject: bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode
Date: Wed, 25 Feb 2015 06:20:36 +0000 [thread overview]
Message-ID: <87sidu3423.fsf@violet.siamics.net> (raw)
In-Reply-To: <83lhjrcwy6.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 21 Feb 2015 13:42:41 +0200")
>>>>> 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
next prev parent reply other threads:[~2015-02-25 6:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-19 17:15 bug#19903: 24.4; Emacs fails to save enriched buffer with error message `wrong-type-argument symbolp "bold"' Jorge
2015-02-19 18:48 ` bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode Ivan Shmakov
2015-02-20 8:27 ` bug#19903: 24.4; Emacs fails to save enriched buffer with error message `wrong-type-argument symbolp "bold"' Eli Zaretskii
2015-02-20 8:51 ` Jorge
2015-02-20 9:12 ` bug#19903: 24.4; wrong-type-argument symbolp "bold" during enriched-encode Ivan Shmakov
2015-02-20 10:07 ` Eli Zaretskii
2015-02-20 17:18 ` Stefan Monnier
2015-02-20 18:56 ` Ivan Shmakov
2015-02-20 19:55 ` Stefan Monnier
2015-02-20 21:09 ` Ivan Shmakov
2015-02-21 11:12 ` Ivan Shmakov
2015-02-21 11:42 ` Eli Zaretskii
2015-02-25 6:20 ` Ivan Shmakov [this message]
2015-02-25 16:06 ` Eli Zaretskii
2015-02-25 17:10 ` Ivan Shmakov
2015-02-25 17:43 ` Eli Zaretskii
2015-02-25 17:55 ` Ivan Shmakov
2015-02-21 12:12 ` bug#19912: facemenu-add-face: does not handle 'face being set to a property list Ivan Shmakov
2015-02-25 7:05 ` Ivan Shmakov
2015-02-25 17:24 ` Ivan Shmakov
2015-02-26 18:12 ` Ivan Shmakov
2015-02-20 10:03 ` bug#19903: 24.4; Emacs fails to save enriched buffer with error message `wrong-type-argument symbolp "bold"' Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sidu3423.fsf@violet.siamics.net \
--to=ivan@siamics.net \
--cc=19903@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.