From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Why does help-fns--first-release not key on `' delimiters? Date: Sun, 09 Jan 2022 18:42:13 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29068"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Emacs-Devel List To: Robin Tarsiger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 10 00:43:04 2022 Return-path: Envelope-to: ged-emacs-devel@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 1n6hq4-0007Ng-Bg for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Jan 2022 00:43:04 +0100 Original-Received: from localhost ([::1]:56186 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n6hq2-00021b-Td for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Jan 2022 18:43:02 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34644) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6hpN-0001Mf-Jq for emacs-devel@gnu.org; Sun, 09 Jan 2022 18:42:21 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15275) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n6hpL-0000Yu-2j for emacs-devel@gnu.org; Sun, 09 Jan 2022 18:42:20 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C19FA4419F3; Sun, 9 Jan 2022 18:42:16 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1A5B24419F8; Sun, 9 Jan 2022 18:42:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1641771735; bh=ywOMEBWxsEiVkXVLjR9EGKK1xe3m5wXHCfnWyU0JoyY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=KglwLUeZ5GnJk5Etw3lbHO2CY6S7qxXMcuHu6B0VJz8MeO+Qg0qKcGgSdrvUnEfcC gM7veszQ4MaD7rff4f9sXC9zDTB46Yyv4v4fXpqOFdYzyavx8M1hmrVyaC1YAaMS9o sWnHIqBR8UXfC3YKGYhj4//le2XYvHWSXoIwuItaFVFeEFYoe8axl5QXWwwuODaofp 2Uks+fRcv8i5lPNZiZ8ZA+pXa9n9F/tsdxWSBCEeLK7H/1Uu6EEdLy/Q99MY9/pyB2 qP9Dd0jCjvn9pPAtdo1r4lZoyJvkowkU4Po+VV09C31FyyGkKAx0fsWU9N+TIreQ2f 6UEbifLvz35vQ== Original-Received: from ceviche (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E69FA12025D; Sun, 9 Jan 2022 18:42:14 -0500 (EST) In-Reply-To: (Robin Tarsiger's message of "Thu, 6 Jan 2022 10:58:35 -0600") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:284513 Archived-At: FWIW, here's what we should do: - Require '...' delimiters. - Fix the etc/NEWS* files accordingly. Fixing them all is likely to be a lot of work, but we can probably make this work very tractable in the following way: - Use a `mapatoms` loop to collect for all the builtin functions&variables the position that the current code finds in the etc/NEWS* files. - Change the code to require '...' delimiters and re-run that `mapatoms` loop. - Compare the outputs: whenever they're different, check the etc/NEWS* to see where's the "real" position and fix the etc/NEWS* so the new code finds it. Stefan Robin Tarsiger [2022-01-06 10:58:35] wrote: > So, for some context first: > > Recently, I went to check when the tagged record type had been added to > Emacs, and typed C-h f record, only to see: > >> (record TYPE &rest SLOTS) >> >> Probably introduced at or before Emacs version 1.9. > > This didn't seem right at all, and unfortunately, the NEWS.1-17 line it > linked to was part of the following paragraph: > >> ** write-kbd-macro and append-kbd-macro are used to save >> a kbd macro definition in a file (as Lisp code to >> redefine the macro when the file is loaded). >> These commands differ in that write-kbd-macro >> discards the previous contents of the file. >> If given a prefix argument, both commands >> record the keys which invoke the macro as well as the > ^^^^^^ >> macro's definition. > > This is a very silly result. (For the, er, record, the _actual_ NEWS > entry for record types is at NEWS.26:1507, under the section for Lisp > changes in Emacs 26.1.) > > Looking at the function help-fns--first-release that generates this > text, it looks like it just searches for the symbol name. However, it > seems to be conventional in these NEWS files for important symbols to > be surrounded by `' pseudo-quotes, just like in e.g. elisp docstrings. > > Is there a reason help-fns--first-release doesn't already expect these? > Presumably the matching is best-effort to begin with, and this seems > like it could eliminate a lot of false positives. > > It's not costless, of course; one counterexample I saw is that Emacs 17's > section on renaming `dot' to `point' in various symbols doesn't use those > delimiters around each of the indvidual names: > >> ** `dot' renamed `point'. >> >> The word `dot' has been replaced with `point' in all >> function and variable names, including: >> >> point, point-min, point-max, >> point-marker, point-min-marker, point-max-marker, >> window-point, set-window-point, >> point-to-register, register-to-point, >> exchange-point-and-mark. >> >> The old names are still supported, for now. > > but at first glance this seems like an acceptable tradeoff. > > Thoughts? > > -RTT