From: Eli Zaretskii <eliz@gnu.org>
To: "Clément Pit-Claudel" <cpitclaudel@gmail.com>
Cc: 41200@debbugs.gnu.org, andlind@gmail.com
Subject: bug#41200: Displaying a tooltip with x-show-tip gets very slow as more faces are defined
Date: Fri, 15 May 2020 20:28:11 +0300 [thread overview]
Message-ID: <833681glas.fsf@gnu.org> (raw)
In-Reply-To: <e47117f7-6f19-9ef5-39ba-8220dfd0980f@gmail.com> (message from Clément Pit-Claudel on Fri, 15 May 2020 12:22:53 -0400)
> Cc: 41200@debbugs.gnu.org, Anders Lindgren <andlind@gmail.com>
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Fri, 15 May 2020 12:22:53 -0400
>
> >>> face_hash_table?
> >>
> >> Thanks, good idea. I also liked Stefan's frame_face_map.
> >
> > "Map" is too general, IMO, it doesn't tell enough about the kind of
> > object it is.
>
> Got it. Is face_table better? (that was Stefan's other suggestion)
Is anything wrong with face_hash_table?
> > I thought about updating the alist when the hash-table is modified.
> > Since you always know whether the face is already in the hash-table,
> > you don't need to scan the alist looking for it.
>
> Would that be done in C, or in any place where frame-new-face-defaults is modified? (for example, edebug changes face-new-frame-defaults in one place; if we keep the alist in addition to the hash table, would it modify both or would there be a C mechanism that mirrors hash-table modifications to the alist?)
The latter was what I had in mind.
> I have a variant of the patch that keeps the alist variable, but I fear that it's worse than removing it: since changes to the alist won't be propagated to the hash table, it might be better to error out with a compilation error?
Not sure yet, it depends on how this is used.
> Btw, I have one more question: some callers of face-list seems to rely on the order of faces added to it, so it would be better to preserve that order. Since hash-tables are not necessarily ordered, should I sort faces by face-id before returning them?
Yes, I think so.
> > I think the problem is that tab-line is declared a basic face, but its
> > defface form is not in faces.el.
>
> Ah, good catch. Current there's a defface for tab-bar in lisp/tab-bar, and since that's preloaded it works, but the defface for tab-line is in lisp/tab-line.el and so isn't preloaded.
> Should I move both to faces.el?
Yes, I think so.
> >>> I'm not sure I understand why do you need to look at the existing
> >>> face's 'face' property? The original code didn't.
> >>
> >> The original code iterated over face-frame-alist in the order in which entries were added to it. If I understand correctly, iteration order isn't guaranteed on hash tables (is it?), so I had to find a different source of truth for these.
> >
> > Maybe we should store the ID with the face? I think we wanted to get
> > rid of the 'face' property of the faces at some point.
>
> Sounds reasonable; but where would we store it? Right now faces are just symbols, right?
Don't hash-tables allow us to store more than one item in each slot?
> > No, I was asking why not start with it as nil and actually make a
> > hash-table when we first need it.
>
> Oh, I thought it would be simpler to always have a hash table instead of having to sanity check every time.
What is the default size of a hash-table?
next prev parent reply other threads:[~2020-05-15 17:28 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-12 4:30 bug#41200: Displaying a tooltip with x-show-tip gets very slow as more faces are defined Clément Pit-Claudel
2020-05-12 6:42 ` martin rudalics
2020-05-12 11:30 ` Clément Pit-Claudel
2020-05-12 15:12 ` martin rudalics
2020-05-12 17:19 ` Clément Pit-Claudel
2020-05-12 17:42 ` martin rudalics
2020-05-12 17:58 ` Eli Zaretskii
2020-05-13 14:58 ` martin rudalics
2020-05-12 15:27 ` Eli Zaretskii
2020-05-13 2:41 ` Clément Pit-Claudel
2020-05-13 14:58 ` martin rudalics
2020-05-13 15:13 ` Clément Pit-Claudel
2020-05-13 17:42 ` martin rudalics
2020-05-15 11:05 ` Eli Zaretskii
2020-05-15 14:59 ` Clément Pit-Claudel
2020-05-15 15:17 ` Eli Zaretskii
2020-05-15 15:33 ` Noam Postavsky
2020-05-15 16:22 ` Clément Pit-Claudel
2020-05-15 17:28 ` Eli Zaretskii [this message]
2020-05-15 18:50 ` Clément Pit-Claudel
2020-05-15 19:05 ` Eli Zaretskii
2020-05-15 19:23 ` Clément Pit-Claudel
2020-05-15 19:38 ` Eli Zaretskii
2020-05-15 19:52 ` Clément Pit-Claudel
2020-05-16 23:03 ` Juri Linkov
2020-05-16 23:43 ` Clément Pit-Claudel
2020-05-17 21:59 ` Juri Linkov
2020-05-18 1:19 ` Clément Pit-Claudel
2020-05-19 21:48 ` Juri Linkov
[not found] ` <83a71z135p.fsf@gnu.org>
2020-05-23 22:47 ` Juri Linkov
2020-05-24 2:33 ` Eli Zaretskii
2020-05-24 21:50 ` Juri Linkov
2020-06-08 0:21 ` Juri Linkov
2020-06-20 7:47 ` Eli Zaretskii
2020-06-20 16:55 ` Clément Pit-Claudel
2020-07-04 7:58 ` Eli Zaretskii
2020-09-13 2:53 ` Benson Chu
2020-05-15 14:03 ` Stefan Monnier
2020-05-15 14:34 ` Eli Zaretskii
2020-05-15 19:10 ` Clément Pit-Claudel
2020-05-15 21:23 ` Stefan Monnier
2020-05-16 8:45 ` martin rudalics
2021-04-06 6:35 ` Jashank Jeremy
2021-04-06 12:30 ` Eli Zaretskii
2021-04-06 15:07 ` Clément Pit-Claudel
2021-04-06 15:50 ` Eli Zaretskii
2021-04-23 3:56 ` Stefan Monnier
2021-05-12 20:29 ` Lars Ingebrigtsen
2021-05-13 3:56 ` Jashank Jeremy
2021-05-13 9:15 ` Lars Ingebrigtsen
2021-05-13 23:26 ` Jashank Jeremy
2021-06-12 12:15 ` Lars Ingebrigtsen
2021-06-13 3:19 ` Richard Stallman
2021-07-06 12:41 ` Aaron Jensen
2021-07-21 14:02 ` Lars Ingebrigtsen
2021-07-21 14:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-21 14:32 ` Clément Pit-Claudel
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=833681glas.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=41200@debbugs.gnu.org \
--cc=andlind@gmail.com \
--cc=cpitclaudel@gmail.com \
/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.