From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#64391: buffer narrowing slowdown regression in emacs 29 Date: Sat, 08 Jul 2023 17:42:19 -0400 Message-ID: References: <87r0psb51z.fsf@ust.hk> <0AD15A09-F669-48C0-AF5C-971D52F5BF8E@gmail.com> <83v8f3q1ff.fsf@gnu.org> <50A46AAC-2089-45CB-A355-CCB2B4EA8D76@gmail.com> <5995c9ed6a0b39c3070c@heytings.org> <83a5wak1tr.fsf@gnu.org> <26cee506f708f3c6cfe1@heytings.org> <26cee506f70bbc9de58b@heytings.org> <83h6qghpdc.fsf@gnu.org> <26cee506f77e9c87e325@heytings.org> <06A8380F-08A6-464E-9946-02F8498031EC@gmail.com> <239e2a5aa11924a2f1d3@heytings.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2524"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: acohen@ust.hk, 64391@debbugs.gnu.org, mattias.engdegard@gmail.com, eliz@gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 08 23:43:21 2023 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 1qIFi4-0000Tw-R6 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 08 Jul 2023 23:43:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qIFhn-0003PV-W8; Sat, 08 Jul 2023 17:43:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIFhm-0003P9-8n for bug-gnu-emacs@gnu.org; Sat, 08 Jul 2023 17:43:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qIFhm-0002ZX-0Q for bug-gnu-emacs@gnu.org; Sat, 08 Jul 2023 17:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qIFhl-0007V3-Nz; Sat, 08 Jul 2023 17:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bugs@gnus.org Resent-Date: Sat, 08 Jul 2023 21:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64391 X-GNU-PR-Package: emacs,gnus X-Debbugs-Original-Cc: acohen@ust.hk, 64391@debbugs.gnu.org, mattias.engdegard@gmail.com, eliz@gnu.org, bugs@gnus.org Original-Received: via spool by 64391-submit@debbugs.gnu.org id=B64391.168885254928752 (code B ref 64391); Sat, 08 Jul 2023 21:43:01 +0000 Original-Received: (at 64391) by debbugs.gnu.org; 8 Jul 2023 21:42:29 +0000 Original-Received: from localhost ([127.0.0.1]:45298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIFhE-0007Tg-KW for submit@debbugs.gnu.org; Sat, 08 Jul 2023 17:42:28 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30053) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIFhD-0007TU-1C for 64391@debbugs.gnu.org; Sat, 08 Jul 2023 17:42:27 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7AF44440C82; Sat, 8 Jul 2023 17:42:21 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 164CB440C43; Sat, 8 Jul 2023 17:42:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1688852540; bh=69k5JFP70NdrG7tDwrxx4Kwg//Q60AIVEsR8vl2FqQY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=F68cQ13XpbR3Z1jUpFPBtgeta1YstKdFRmhEFJvuzkkNV/DsFHuMhWSMoBvEVFjzW RRFphts1QA9NoMAayOzdQKSrJxpsmESvBJh2wT49+AG7WEW9nP7uiO/j1uv6oPeWCa sEc+Ds05nXXPpIv1ogwtfMtkixqgpB2mvrZRf/tVvUh6MMtwRma/FssB7ynl9QpIMm qgeKZ53XXXj9sYUAhdrWEPwYlIAMxXP8EfB9sJbDHRtHgl9Nu9aWxavhE7R+x1kPkg cQJXEElmvIiMYJyb1aQSnHzl+0JAi1EFtw/y0EZSXL+gUYTFxY8uWzVj4GaSSwTU7p 6oDLYOlPmPf5Q== Original-Received: from pastel (unknown [24.140.234.50]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D1FDA1202A0; Sat, 8 Jul 2023 17:42:19 -0400 (EDT) In-Reply-To: <239e2a5aa11924a2f1d3@heytings.org> (Gregory Heytings's message of "Sat, 08 Jul 2023 20:58:44 +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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264800 Archived-At: >>> I'm sorry, I don't understand your question. The only way (except by >>> using internal functions) to enter a labeled restriction is to use the >>> with-restriction special form with its optional label argument. >> Nitpick: it's not a special form, it's a macro. There's a *big* >> difference because adding a special form requires changing >> `macroexpand-all`, the compiler, yadayada, and it introduces backward >> incompatibilities with packages doing their own code-walks. > TIL. I thought that "special form" and "macro" were more or less synonyms. > The manual describes lambda, prog2, setq-default, dlet, letrec, named-let, > with-suppressed-warnings, with-no-warnings, with-restriction and > without-restriction as "special forms", although they are in fact macros. You're right: from a programmer's stand point the distinction doesn't really matter. It matters only from the point of view of the language implementer. For some reason it tripped me, here (I went looking at the code fearing that we were using an actual special form). Sorry 'bout that, move along, nothing to see :-) >> BTW, "LABEL is a symbol" sends the wrong message (a quoted symbol >> evaluates to a symbol but it's not itself a symbol). IOW the docstring >> should clarify that LABEL is an expression that's evaluated at runtime >> (and should return a symbol). While I'm here, is it important that LABEL >> evaluates to a symbol? Or is it like `catch/throw` where we expect most >> uses to use a symbol but where any other (non-nil) value works as well? > > The latter: it's like catch/throw, it's intended to use with a symbol but it > could be any non-nil value. So one could write something similar to what is > found in the docstring of catch: "LABEL is evalled to get the label to use, > it must not be nil". +1 from me, Stefan