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

Previous Next

Package: emacs;

Reported by: No Wayman <iarchivedmywholelife <at> gmail.com>

Date: Tue, 23 Jan 2024 03:46:01 UTC

Severity: normal

Tags: confirmed

Merged with 68821

Fixed in version 30.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Mekeor Melire <mekeor <at> posteo.de>, john muhl <jm <at> pub.pink>, 68668 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Andrea Corallo <acorallo <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#68668: 30.0.50; Invalid hash table test: tab-bar--auto-width-hash-test
Date: Wed, 31 Jan 2024 14:34:52 +0100
Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> 31 jan. 2024 kl. 14.05 skrev Gerd Möllmann <gerd.moellmann <at> gmail.com>:
>
>> why not reuse an existing entry for a given name?
>
> We mustn't violate invariants of existing hash-table objects when the
> test is redefined. Consider:
>
> (define-hash-table-test 'mytest #'cmp1 #'hash1)
> (setq h (make-hash-table :test 'mytest))
> ...
> (define-hash-table-test 'mytest #'cmp2 #'hash2)
> ; h must still use cmp1 and hash1 at this point

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. 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.

Just my 2 cents.




This bug report was last modified 1 year and 172 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.