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

[Mattias Engdegård]

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!