bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

31 jan. 2024 kl. 14.34 skrev Gerd Möllmann <gerd.moellmann@gmail.com>:

> But that also means that we end up with two sorts of hash-tables that
> behave differently, without us being able to tell them apart, because
> hash-table-test returns 'mytest for both.

This is how elisp hash tables worked in Emacs 29; I didn't change that part, I think.

> I think I'd prefer if that
> were not the case, and the redefinition would apply to both. If an old
> hash-table then behaves stragely, I know what's up, and can empty it, if
> it isn't still empty in the first place.

I'm not really happy with that sort of spooky action at a distance because it makes it too easy not only to introduce mysterious behaviour but also violate invariants that the C implementation relies upon for the management of an internal data structure.

That said, it is true that Lisp permits retroactive dynamism in several places even with the current design: the test and hash functions can both be redefined, and of course all code in Lisp is potentially impure and can change behaviour when its environment changes.

I still believe the current semantics cause fewer user headaches on balance. In any case, it probably should be documented in the `define-hash-table-test` doc string.

But you do raise an interesting point, thank you!