From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 43397@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
Caio Henrique <caiohcs0@gmail.com>
Subject: bug#43397: 28.0.50; Adding tool bar items: update tool bar
Date: Tue, 03 May 2022 13:53:21 -0400 [thread overview]
Message-ID: <jwvilqmms1w.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87ilqmvaco.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 03 May 2022 18:39:51 +0200")
Lars Ingebrigtsen [2022-05-03 18:39:51] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> `tool-bar-map` is a normal keymap, which we modify in the usual way,
>> i.e. via side-effect. So the key we place in this `equal` hash table
>> will be routinely modified via side-effect, thus changing its sxhash.
> Hm... I assumed that that was the point, really, but that it didn't
> work for... reasons... I.e., whenever somebody modifies the map, the
> cache is supposed to be refreshed. I don't understand why that didn't
> work, but it doesn't.
Since the key is stored as-is in the hash table, modifying the key and
looking it up again should find it its hash value is unchanged, and the
`equal` test will return t since both the in-hashtable key and the
lookup-key are one and the same object.
In any case side effects on a key's stored in an `equal` hash table lead
in general to the hash table having an inconsistent internal state, so
they should be avoided as much as possible.
[ Just like using `aset` on the `symbol-name` of an interned symbol,
for the same reason. ]
Stefan
next prev parent reply other threads:[~2022-05-03 17:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 14:30 bug#43397: 28.0.50; Adding tool bar items: update tool bar Caio Henrique
2020-09-14 21:44 ` Caio Henrique
2020-09-15 15:27 ` Eli Zaretskii
2020-09-15 20:05 ` Stefan Monnier
2020-09-16 2:26 ` Eli Zaretskii
2021-08-27 17:40 ` Lars Ingebrigtsen
2021-08-27 22:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-28 15:30 ` Lars Ingebrigtsen
2022-05-03 15:28 ` Lars Ingebrigtsen
2022-05-03 15:41 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-03 16:09 ` Lars Ingebrigtsen
2022-05-03 16:19 ` Lars Ingebrigtsen
2022-05-03 16:49 ` Eli Zaretskii
2022-05-03 16:50 ` Lars Ingebrigtsen
2022-05-03 16:31 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-05-03 16:39 ` Lars Ingebrigtsen
2022-05-03 16:46 ` Lars Ingebrigtsen
2022-05-03 16:54 ` Eli Zaretskii
2022-05-03 16:57 ` Lars Ingebrigtsen
2022-05-03 17:53 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-05-03 18:58 ` Lars Ingebrigtsen
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=jwvilqmms1w.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=43397@debbugs.gnu.org \
--cc=caiohcs0@gmail.com \
--cc=eliz@gnu.org \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
/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.