From: Keith David Bershatsky <esq@lawlist.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Adding new variable for face-list in internal-make-lisp-face.
Date: Sat, 04 Nov 2017 10:46:17 -0700 [thread overview]
Message-ID: <m2mv42q6mu.wl%esq@lawlist.com> (raw)
What a wonderful treat it was to check my emails this morning and find the ingredients to properly calculating faces and its components! :)
I ran into one little `emacs_abort` snag this morning while trying the following two test snippets, which came about when I changed the face background with `face-remap-add-relative` on a face that had been previously defined with `defface`.
Should I run a pre-test for all 15 cases in lookup_basic_face to see if it would throw an `emacs_abort`, and then *only* call lookup_basic_face if success is guaranteed?
Alternatively, perhaps using it.face_id obviates the need to use lookup_basic_face?
TEST SNIPPETS:
struct face *tab_face = FACE_FROM_ID (f, lookup_basic_face (f, it.face_id));
Lisp_Object tab_bg = tab_face->lface[LFACE_BACKGROUND_INDEX];
AUTO_STRING (my_string_one, "IT background: %s");
CALLN (Fmessage, my_string_one, tab_bg);
#ifdef GLYPH_DEBUG
debug_method_add (w, "face_id: %d", it.face_id);
#endif
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
DATE: [11-04-2017 01:13:33] <04 Nov 2017 10:13:33 +0200>
FROM: Eli Zaretskii <eliz@gnu.org>
>
> * * *
>
> Face IDs are ephemeral, because Emacs frees all faces and realizes
> them anew from time to time, when it thinks the previous definitions
> might be invalid. E.g., when the attributes of the default face
> change, all the faces need to be recomputed, because many of them
> inherit from the default face.
>
> So if you use the face ID, you need to recompute it each time you need
> it. You cannot compute it once and then reuse the same value, because
> sooner or later it will become invalid.
>
> * * *
>
> See next_element_from_display_vector for how the faces of glyphs from
> a display table are used to display those glyphs. And because of what
> I said above, once you have the face ID, you need to use lookup_*_face
> functions to get the face corresponding to that ID.
> * * *
>
> I believe I already explained how to get the fore- and back-ground
> colors of a face given its ID in my message Re: Can we use FRAME_RIF
> to return a Lisp_Object result? I think you should use the same
> technique here.
next reply other threads:[~2017-11-04 17:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-04 17:46 Keith David Bershatsky [this message]
2017-11-04 18:16 ` Adding new variable for face-list in internal-make-lisp-face Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2017-11-04 6:56 Keith David Bershatsky
2017-11-04 8:13 ` Eli Zaretskii
2017-11-03 22:01 Keith David Bershatsky
2017-11-04 8:05 ` Eli Zaretskii
2017-11-03 3:50 Keith David Bershatsky
2017-11-03 10:17 ` 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2mv42q6mu.wl%esq@lawlist.com \
--to=esq@lawlist.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).