From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#52053: 29.0.50; Nonsensical button "C-x C-f" in scratch buffer Date: Mon, 29 Nov 2021 09:59:57 -0800 Message-ID: References: <87czmr5gr7.fsf.ref@yahoo.com> <87czmr5gr7.fsf@yahoo.com> <612d659daa29af13c2e5@heytings.org> <83y25c5wn0.fsf@gnu.org> <612d659daabc268505c4@heytings.org> <83pmqo5vmp.fsf@gnu.org> <612d659daad03d6bc73d@heytings.org> <834k805nil.fsf@gnu.org> <612d659daa026d901515@heytings.org> <83v90g467g.fsf@gnu.org> <612d659daa5de288a9f9@heytings.org> <83czmn4ekx.fsf@gnu.org> <227d35a5bc44057cc87b@heytings.org> <227d35a5bceaf01c97c4@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30786"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: luangruo@yahoo.com, 52053@debbugs.gnu.org, larsi@gnus.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 29 19:01:17 2021 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 1mrkxo-0007oH-Fp for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Nov 2021 19:01:16 +0100 Original-Received: from localhost ([::1]:53244 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mrkxn-0000nR-At for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 29 Nov 2021 13:01:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mrkxa-0000l3-Kt for bug-gnu-emacs@gnu.org; Mon, 29 Nov 2021 13:01:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55955) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mrkxa-0007jW-C5 for bug-gnu-emacs@gnu.org; Mon, 29 Nov 2021 13:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mrkxa-0004xR-6R for bug-gnu-emacs@gnu.org; Mon, 29 Nov 2021 13:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Nov 2021 18:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52053 X-GNU-PR-Package: emacs Original-Received: via spool by 52053-submit@debbugs.gnu.org id=B52053.163820880518906 (code B ref 52053); Mon, 29 Nov 2021 18:01:02 +0000 Original-Received: (at 52053) by debbugs.gnu.org; 29 Nov 2021 18:00:05 +0000 Original-Received: from localhost ([127.0.0.1]:39268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mrkwf-0004ur-CA for submit@debbugs.gnu.org; Mon, 29 Nov 2021 13:00:05 -0500 Original-Received: from mail-pg1-f179.google.com ([209.85.215.179]:34752) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mrkwd-0004ts-6R for 52053@debbugs.gnu.org; Mon, 29 Nov 2021 13:00:03 -0500 Original-Received: by mail-pg1-f179.google.com with SMTP id 200so16927686pga.1 for <52053@debbugs.gnu.org>; Mon, 29 Nov 2021 10:00:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=dL0JuKB7lf7HIQAIXisiLRudH5abhLF31hkghomFc7U=; b=wdVcMGlLR12vSrdoJABNGBc1vo5yo1HV/Ad+CcPTYXIJRgkUCCxT69QK6PCZmFn0zP 5aKZZw6t/ORkqCAlXa0Ug5S/fvMrrTI1+qmX930pwdnMtrY2tMLUDcbuJmyUSyEym5Jl NJgC+bcr/9JMqXsYRigClvAg9cybUF6l3UJmorvOiuw4cGcPmK//+M6hmMzloGLEzNw5 26WkJ7Kfrez/+nleXClpOCnrxnDm2q5+q/rgk0sk8DYZ44vd41/b2IPiSGggImBtyqpC 8mns5hjnuUqLYepF/Wp+UtllA3MtMeOuHU/KrABBkzwNgC+PijCznfO3jimy7GjOxTYa 7BmA== X-Gm-Message-State: AOAM5319tRw7Y8aSDb3rxbkEs62Plm9xvVelfzCByUanggKnoQuNO5fv AdbYY8bwRxHPkcnJtShQPDRVJUEy7PB5fISXVhM= X-Google-Smtp-Source: ABdhPJyUq9Oh0CS35qSl0AiN/KLixoNQPKNucH0057xap3EFPBJIN3lRckae1nxeKCTbw19HmzrEmp5A2Ts09ITSRoM= X-Received: by 2002:a05:6a00:244d:b0:44d:c279:5155 with SMTP id d13-20020a056a00244d00b0044dc2795155mr40202822pfj.0.1638208797348; Mon, 29 Nov 2021 09:59:57 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 29 Nov 2021 09:59:57 -0800 In-Reply-To: <227d35a5bceaf01c97c4@heytings.org> (Gregory Heytings's message of "Sat, 27 Nov 2021 16:08:57 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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:221052 Archived-At: [[Sorry for the late comments here.]] Gregory Heytings writes: > Attached. The basic idea sounds good to me, but I have some minor questions: > diff --git a/lisp/apropos.el b/lisp/apropos.el [snip] > + (let ((help-buffer-under-preparation t)) > + (help-setup-xref (list 'apropos-describe-plist symbol) > + (called-interactively-p 'interactive)) > + (with-help-window (help-buffer) > + (set-buffer standard-output) > + (princ "Symbol ") > + (prin1 symbol) > + (princ (substitute-command-keys "'s plist is\n (")) > + (put-text-property (+ (point-min) 7) (- (point) 14) > + 'face 'apropos-symbol) > + (insert (apropos-format-plist symbol "\n ")) > + (princ ")")))) I'm fine with this but I ask myself if binding this variable should be done in a macro (perhaps `with-help-window'?). I'm too under the weather to look at or think about this properly, so I'll just leave you with the question. > +(defvar help-buffer-under-preparation nil > + "Whether a *Help* buffer is being prepared. > +This variable is bound to t during the preparation of a *Help* > +buffer.") Should we document what the practical effect of this is, instead of when it is t? Perhaps related, is this the best name for this variable? Finally, does this call for updating the docstring of `help-link-key-to-documentation'?