From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#53242: [PATCH] unify reads from local_var_alist Date: Fri, 14 Jan 2022 21:01:49 +0200 Message-ID: <83ilum16qq.fsf@gnu.org> References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> <83zgny20z2.fsf@gnu.org> <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1396"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53242@debbugs.gnu.org To: Sergey Vinokurov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 14 20:03:20 2022 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 1n8Rr6-0000Aa-1D for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jan 2022 20:03:20 +0100 Original-Received: from localhost ([::1]:59540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n8Rr4-0005hC-UP for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jan 2022 14:03:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33454) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8Rqo-0005ea-Bn for bug-gnu-emacs@gnu.org; Fri, 14 Jan 2022 14:03:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45248) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n8Rqo-0008Qs-2T for bug-gnu-emacs@gnu.org; Fri, 14 Jan 2022 14:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n8Rqn-0001x4-Vv for bug-gnu-emacs@gnu.org; Fri, 14 Jan 2022 14:03:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jan 2022 19:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53242 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 53242-submit@debbugs.gnu.org id=B53242.16421869267406 (code B ref 53242); Fri, 14 Jan 2022 19:03:01 +0000 Original-Received: (at 53242) by debbugs.gnu.org; 14 Jan 2022 19:02:06 +0000 Original-Received: from localhost ([127.0.0.1]:38145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8Rpu-0001vO-6D for submit@debbugs.gnu.org; Fri, 14 Jan 2022 14:02:06 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:60576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8Rpr-0001un-5R for 53242@debbugs.gnu.org; Fri, 14 Jan 2022 14:02:05 -0500 Original-Received: from [2001:470:142:3::e] (port=53434 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8Rpl-0008Jc-Rt; Fri, 14 Jan 2022 14:01:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dMtoRcVx8RDl+1yiIISOBbECDdeXSRbGPc1Wttm35YU=; b=EKBizD9LuLlt ektolznXune5qJ73it0xeF8RPLuqROAvQE2PvEbwXrQF1Psyj4lA33a4E2G3AZV8LD4AzHYjdn7IU XHOiiTPPymEkVL6tOV6ZJj1TeGDlLYT90EfUqht9PSvSO29is7q0y+2jY/mDIumHfZBZ+H7Vhmz8H 9kbY/x5/Kh++iBmq0DAOp0ypeCVDrFxG727Gnov0h/VunNv3KMuv5TqnOvOxOiEK1JjeiyKQcInK1 nnuX+62xpr4TZkSZtCCj7ZTm3i8kmN0HxXNSSXnIAJ58B8lzxhdOq6Nk0dM1bQKEmqd4jxE2wPBX3 B/bYkOxCb3/fhkMBrbB9Fg==; Original-Received: from [87.69.77.57] (port=2521 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8Rpl-0004be-TJ; Fri, 14 Jan 2022 14:01:58 -0500 In-Reply-To: <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> (message from Sergey Vinokurov on Fri, 14 Jan 2022 18:37:45 +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:224231 Archived-At: > Date: Fri, 14 Jan 2022 18:37:45 +0000 > Cc: 53242@debbugs.gnu.org > From: Sergey Vinokurov > > > How long can local_var_alist be? This change will not allow the user > > to C-g from a long search. Do we care? How about using Fassq > > consistently instead? > > This list is not directly observed by the user. The lookups happen > during reads and writes of the buffer-local variables so if it's really > slow the only effect user would observe is that elisp got slow. There's > no single point for the user to C-g from. ?? What do you mean? Long operations in Emacs generally periodically check for user's quitting, andif they detect C-g, they throw to top-level. assq_no_quit doesn't. > This list definitely cannot be longer than a list of all the global > variables ever defined. This upper bound is probably a high number, but > not astronomically high. The question I asked was: it high enough to cause annoyingly long operations in some cases, and whether we care that users will no longer be able to interrupt such long operations. You seem to assume that the number cannot be high enough, but I see no basis for that assumption in what you wrote.