From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#39529: 28.0.50; Metahelp does not contain help text Date: Wed, 19 Feb 2020 02:34:39 +0000 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" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="113335"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39529@debbugs.gnu.org, federicotedin@gmail.com To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 19 03:36:14 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 1j4FDg-000TKv-Gd for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Feb 2020 03:36:12 +0100 Original-Received: from localhost ([::1]:44716 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4FDf-0006bp-Fk for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 18 Feb 2020 21:36:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48462) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4FDX-0006bf-R8 for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 21:36:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4FDW-0000aY-I9 for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 21:36:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35532) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4FDW-0000aO-En for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 21:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j4FDW-0004EU-Bh for bug-gnu-emacs@gnu.org; Tue, 18 Feb 2020 21:36:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Feb 2020 02:36:02 +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.158207972316216 (code B ref 39529); Wed, 19 Feb 2020 02:36:02 +0000 Original-Received: (at 39529) by debbugs.gnu.org; 19 Feb 2020 02:35:23 +0000 Original-Received: from localhost ([127.0.0.1]:41505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4FCt-0004DT-7F for submit@debbugs.gnu.org; Tue, 18 Feb 2020 21:35:23 -0500 Original-Received: from mail-ot1-f47.google.com ([209.85.210.47]:39092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4FCs-0004DD-7O for 39529@debbugs.gnu.org; Tue, 18 Feb 2020 21:35:22 -0500 Original-Received: by mail-ot1-f47.google.com with SMTP id 77so21669056oty.6 for <39529@debbugs.gnu.org>; Tue, 18 Feb 2020 18:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=csse3FOL92fpzWbNyySsnIEOK8hLbvGLH4t6vZldsJg=; b=fO1uwBZhK4QmW6v6g9fMZeOQzJ7G8CmiUP4FHsR0VAHHBHKB0XQqj/Kp5db7341Bzq MJlj7utqhAJzSHzAsj1mvlFBZSdC7ZPyxXaGk6p+7HR6Abef1zlBvBlbxKe5tqaG3HIZ pR8mO0zbnMFwd9okkqmBcOtze+LfJoF9Pq9qfzdqubbJYNPpNkpDjXNMbDAaM/CWoG8f /J5QcIardqTJ4x/221XOGChTKMXuLhnLrsM6gX6FSWdGoKVDGgZ+HYn8QzO/DaJVHpk1 o32Sks8GNHokAAK+TwxXkevoCNc1Pn6nl0wIv6CxMNd+tM5B/fCrKLhCnXK+VcUf5Wra W0pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=csse3FOL92fpzWbNyySsnIEOK8hLbvGLH4t6vZldsJg=; b=gr1EVLpDZL8t8s9UZ55Qnb2wtioB/NHH+Rdv8N25dgL+iseHOSPAK9qwKwGbz77oWQ ncJ8WgaL8dXDTvb4hgeCloP8q4qVrlaf+UMNqrngUJNOND8PxtHuG8NvCIs/aqTDesZa 6d3hLqFDIWzzwwcucASMzbP/W8+4sBAZzkoTxFh36HADtgs/CpnjSXpuY1q6d4IXKWvM XRzWrG4QNbDq6meJ/HGm7rU3qoGK2UKQrdiEQpxEIszMy0bN0rYtDKFJhiW24RyCJgWK Ijr+YIufzbd+b9EmPer1WID2z1+KtbKBKOTASCZaWmEGEWJ8yD/kWiHrTrkZtjOJ4dzH 2CDg== X-Gm-Message-State: APjAAAVy9L0p38ewk56zkg0s4jDJEgC8uwWgNjKcEDFU08lF8BTE0ARP hWgECQeM3NG4STNP/KRzanUd5OEWK/0W2IQqG9k= X-Google-Smtp-Source: APXvYqyV18/9cZ5+JbGPFLSbLEsaqI3d5VXlaMqep547ia/uJbgyVsgYvwc1BMJ89AUerDF8BsK1/P9XzoBmexlFvps= X-Received: by 2002:a9d:7511:: with SMTP id r17mr16753321otk.154.1582079716354; Tue, 18 Feb 2020 18:35:16 -0800 (PST) In-Reply-To: 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:176234 Archived-At: On Wed, Feb 19, 2020 at 1:22 AM Paul Eggert wrote: > > 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". That sentence is what I was referring to by "mutations of hash keys won't cause rehashing", which is one of the deviations. The other one is documented in objects.texi: Comparing circular lists may therefore cause deep recursion that leads to an error, and this may result in counterintuitive behavior such as @code{(equal a b)} returning @code{t} whereas @code{(equal b a)} signals an error. > 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? cmpfn_equal is only called when the numeric hashes are equal, so the actual predicate used is sxhash_equal (a) == sxhash_equal (b) && Fequal (a, b). That diverged from Fequal (a, b) in the case where a and b are markers, for example. > > >>> 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. True. My point was that "equal" is a problematic hash predicate, at least currently. > 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. Agreed. > > 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. (defun hash-equal (a b) (let ((ht (make-hash-table :test 'equal))) (puthash a t ht) (gethash b ht))) (hash-equal (point-marker) (point-marker)) (equal (point-marker) (point-marker))