GNU bug report logs - #39529
28.0.50; Metahelp does not contain help text

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#39529: closed (28.0.50; Metahelp does not contain help text)
Date: Sat, 15 Feb 2020 23:26:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 15 Feb 2020 15:25:44 -0800
with message-id <e1dae7d6-376c-a9f5-b0b6-4ade20dca59b <at> cs.ucla.edu>
and subject line Re: bug#39529: 28.0.50; Metahelp does not contain help text
has caused the debbugs.gnu.org bug report #39529,
regarding 28.0.50; Metahelp does not contain help text
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
39529: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39529
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Federico Tedin <federicotedin <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Metahelp does not contain help text
Date: Sun, 09 Feb 2020 20:06:40 +0100

On Emacs 28.0.50 (5e7bead8ea), typing C-h C-h will display the
*Metahelp* buffer, but instead of containing the usual help information,
it will contain just the following:

Automatically break line at a previous space, in insertion of text.

(which appears to be the document string for `auto-fill-function' in
simple.el).

[Message part 3 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 39529-done <at> debbugs.gnu.org, federicotedin <at> gmail.com
Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text
Date: Sat, 15 Feb 2020 15:25:44 -0800

[Message part 4 (text/plain, inline)]

On 2/9/20 11:34 AM, Eli Zaretskii 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.

[0001-Fix-C-h-C-h-bug-due-to-mutating-a-hash-key.patch (text/x-patch, attachment)]

Previous Next

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