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: Sun, 16 Feb 2020 16:51:38 +0000 Message-ID: References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> 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="119839"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39529-done@debbugs.gnu.org To: 39529@debbugs.gnu.org, eggert@cs.ucla.edu, federicotedin@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 16 17:53:16 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 1j3NAQ-000V3B-H4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Feb 2020 17:53:14 +0100 Original-Received: from localhost ([::1]:34088 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3NAP-00071t-7B for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Feb 2020 11:53:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46589) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3NAF-00070a-Ug for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2020 11:53:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3NAE-0005XB-Sh for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2020 11:53:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59885) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j3NAE-0005Wt-Em for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2020 11:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j3NAE-0001cc-C9 for bug-gnu-emacs@gnu.org; Sun, 16 Feb 2020 11:53: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: Sun, 16 Feb 2020 16:53: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.15818719426181 (code B ref 39529); Sun, 16 Feb 2020 16:53:02 +0000 Original-Received: (at 39529) by debbugs.gnu.org; 16 Feb 2020 16:52:22 +0000 Original-Received: from localhost ([127.0.0.1]:37623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3N9Z-0001bc-UB for submit@debbugs.gnu.org; Sun, 16 Feb 2020 11:52:22 -0500 Original-Received: from mail-oi1-f176.google.com ([209.85.167.176]:34980) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3N9X-0001bK-Sn; Sun, 16 Feb 2020 11:52:20 -0500 Original-Received: by mail-oi1-f176.google.com with SMTP id b18so14499388oie.2; Sun, 16 Feb 2020 08:52:19 -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=Xef/rt+P0JDwUbA1iZHqaYqVW90Aww50YQfMct54sP0=; b=Svptg56GmJml9fvVlwX3HMkkdvCQd8K8jK7FnRQzqnS/cltsf66Py+Q7gUBi++Q7xb Z+gJzerUydQTIv8gYgpwE+tyUXbftciyV5pteRq00/bTWscFwImMajF9MKK9C7lFkAkn WAxIFSxPjojYiOeor5wBgRi6wNcpFsg7tPDxDGl2F+qI1m34SqHLqreNd6ajMbHsYH/g JpaZYzdryjlEXZkKsEM8KniABNdapnAkHqDjr2dW4IMs4m7z2A9Fw3MOSMozC1Tn67Yx zJKn5rEizXa6ZEfLwJ+Ci5CwtHG+zWwpzZvN89MjlcCd2B0275cM1EPpn5u7CSBrDog9 yZfg== 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=Xef/rt+P0JDwUbA1iZHqaYqVW90Aww50YQfMct54sP0=; b=VMpQb1nOGaE71DuZMxzeugiO1c0G5I6lkGp9/MGWl1+XRBxo4XT5rYIN/8mFG7g/uu GD3lBh0v7Rr49SkatngOKLlJ4ce8BY8DXr9/ZAfaW51JWFTiZATmI577UahI8goeDRsV hNsAkzAJOp1tHrfvGm+7cyXGb36Nld90ZHQ56BLWY6nlgKd8Ezpa5ufc4eXo/Gr8tFsz 9DlVz+CBmuJ+r+9gJ2ETP4bLmrkIf5xLmbLeno6nVxctzuiwlN3j0RdvFYxaLmVMB4Ri 23cDIgS7ZTbIBa4vBBW7mHFKFE4pJZ6EmB8Mlt9ZsEjCLhAzATNCPn3Vrr5F8oKtjLvo vlIQ== X-Gm-Message-State: APjAAAWtVqz9u1f0/Cbc71/DlKsWdzHUhP1JZ9cEz6IUJtILXAH0Jz2z GoNs8SUmEovG/FhduQPbXLkA80AwXXDEQIIsQenvysRQ X-Google-Smtp-Source: APXvYqxHtKnY4Fi26W42cGPSYhBofK4+hui03FNi99Pk9pqNe2h6qegKs+U7bBSTnFJFwu3OVafgLYO9cG5Q316dwJg= X-Received: by 2002:aca:5588:: with SMTP id j130mr7441003oib.122.1581871933902; Sun, 16 Feb 2020 08:52:13 -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:176117 Archived-At: On Sat, Feb 15, 2020 at 11:26 PM Paul Eggert wrote: > > I suspect the sxhash changes on Jan 7. This problem started happening > > in that day's build. > > Right you are. The problem was Emacs was using a hash table to unify identical > Lisp compiled objects when purecopying them, even though their doc strings were > not set up yet (and so were 0 placeholders that always compared equal). Formerly > this bug was masked because sxhash simply returned the objects' hashed > addresses, but the January 7 changes unveiled the bug. I install the attached > patch to fix the problem. That works as a quick fix, but it's not perfectly correct, since it relies on different objects having different hashes, and they might, by pure chance, have the same hash. We need to fix the underlying issue, or at least go for the correct "quick fix", which is to make equal = eq for bytecode objects (this is almost indistinguishable from the previous behavior, before sxhash-equal was "fixed"). 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'. And I still suspect many other people have made the same "mistake" as I, of assuming the previous behavior of equal-based hashes for markers and overlays was guaranteed. To recap, the January 7 changes broke code that uses markers or overlays as hash keys (or as components of hash keys) in equal-based hash tables; before the changes, it was safe to do so. After the changes, it's only safe to do if the character positions don't change between storage and lookup, and there's no hint at what might be happening. In summary, I still think the right fix is not to make equal look at more state than sxhash-equal used to, particularly for Emacs 27. We've now seen that the January 7 changes cause follow-up bugs, such as this one, so maybe it's time to reconsider what the right thing to do is here.