From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#39529: 28.0.50; Metahelp does not contain help text Date: Tue, 18 Feb 2020 17:21:58 -0800 Organization: UCLA Computer Science Department Message-ID: References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> <59be714f-1b52-a068-70c8-3204cf016ca2@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="127108"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: 39529@debbugs.gnu.org, federicotedin@gmail.com To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 19 02:23:18 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j4E57-000Wwx-TW for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Feb 2020 02:23:17 +0100 Original-Received: from localhost ([::1]:44082 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4E56-00014q-Sg for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 18 Feb 2020 20:23:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50344) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4E4u-00013E-G9 for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 20:23:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4E4r-00074W-U3 for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 20:23:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35517) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4E4r-00074Q-Pw for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 20:23:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j4E4r-0002MU-Kw for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 20:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Feb 2020 01:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39529 X-GNU-PR-Package: emacs Original-Received: via spool by 39529-submit@debbugs.gnu.org id=B39529.15820753289004 (code B ref 39529); Wed, 19 Feb 2020 01:23:01 +0000 Original-Received: (at 39529) by debbugs.gnu.org; 19 Feb 2020 01:22:08 +0000 Original-Received: from localhost ([127.0.0.1]:41490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4E3z-0002LA-Qz for submit@debbugs.gnu.org; Tue, 18 Feb 2020 20:22:08 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4E3x-0002Ke-CP for 39529@debbugs.gnu.org; Tue, 18 Feb 2020 20:22:06 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id CC6461600AB; Tue, 18 Feb 2020 17:21:59 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id eafC2Yk9BOAO; Tue, 18 Feb 2020 17:21:59 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EFCCC1600B2; Tue, 18 Feb 2020 17:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9klYlsm7R4KW; Tue, 18 Feb 2020 17:21:58 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D2E5C1600AF; Tue, 18 Feb 2020 17:21:58 -0800 (PST) In-Reply-To: Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:176233 Archived-At: On 2/18/20 11:56 AM, Pip Cet wrote: > if we rely on the precise > definitions of XHASH etc. that were in place prior to the January > changes, no "quick fix" was needed; it was simply the case that the > predicate used by hash tables created with :test equal diverged from > the built-in `equal' predicate in one more way than was already > documented. (Those documented deviations are that mutations of hash > keys won't cause rehashing, and that equal will sometimes signal for > (equal a b) but not for (equal b a)). I'm not aware of these deviations - where are they documented? What I see in the Emacs 27 documentation, under "Defining Hash Comparisons", is the statement that the hash and equality functions' "behavior should depend on only on properties of the keys that do not change". This is true of 'equal' and 'sxhash-equal' if one does not mutate any key that's in the hash table. So from what I can see, the predicates are supposed to be the same, it's just that one can't mutate keys. Also, I don't understand what is meant by "the predicate used by hash tables created with :test equal diverged from the built-in `equal' predicate". cmpfn_equal simply calls Fequal, so how can their behaviors diverge? >>> The pure-cons hash, and many other places, assume "equal" means >>> "equivalent" in some way. That's not true for bytecode objects, where >>> a function always returning `nil' can be equal to one always returning >>> `t'. >> >> Could you give an example of this? When I byte-compiled this: > > (defun f () (let ((x '(#1=(nil) . #1#))) > (eq (car x) (cdr x)))) > (defun g () (let ((x '((nil) . (nil))) > (eq (car x) (cdr x)))) > > That's somewhat contrived; more realistic examples where this might > actually be a problem would use string properties. Although this example is a good one that illustrates a bug (or at least a poorly-documented feature) in dumping, it hasn't changed because of the January 7 changes to sxhash. The same issue exists in Emacs 27 (and in Emacs 26 for that matter). So I'd rather address this issue separately, perhaps simply by documenting it for now. > I'll propose one more thing, which sounds horrible at first but might > be the least horrible option: accept that `equal', the function, and > `:test equal', the hash table predicate, have diverged significantly > already. Again I'm not following, because the two functions haven't diverged as far as I can see.