From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 13 19:23:50 2022 Received: (at submit) by debbugs.gnu.org; 14 Jan 2022 00:23:51 +0000 Received: from localhost ([127.0.0.1]:34881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8ANi-0002Tt-Kt for submit@debbugs.gnu.org; Thu, 13 Jan 2022 19:23:50 -0500 Received: from lists.gnu.org ([209.51.188.17]:41774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8ANe-0002Th-Rj for submit@debbugs.gnu.org; Thu, 13 Jan 2022 19:23:50 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58084) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8ANe-0006jj-M1 for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 19:23:46 -0500 Received: from [2a00:1450:4864:20::434] (port=33567 helo=mail-wr1-x434.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n8ANd-0004hA-5i for bug-gnu-emacs@gnu.org; Thu, 13 Jan 2022 19:23:46 -0500 Received: by mail-wr1-x434.google.com with SMTP id d19so13119023wrb.0 for ; Thu, 13 Jan 2022 16:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject; bh=Eac8/OwYQGHobnX6WiSq/aJtrjmz4yFNIw+ihpNACXI=; b=IvuH+LHCGiBQirnVWmMqa7bdpxd5LbTGNmObu/MWEUCWTDi0H52gMRoS1F0b6+vMS4 eZhcO4ZTbDbLlEZHy9cFCbnHry2OKlXOH5ftwpIIT0giqjstW0Ab1AsjMlIcpehtC/Ye gK4GjObJzeyAWoFbA9Sct8PP8B/TNsC62LGuGE3VVKacLOYMB+0o71jvp2QY7YKxftB9 x/u2vtkDmaMKgkeQxx5vTXHEYB787Rzg9iOfADvTQzXk6VEEIfT601sVvB3n/L3vYUeW zvoLVJ0wczVXEenBNvAniqW2vrel7sT8Xij172paujVvsmupGkRvWY+grp/xIICHv9pP yC0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject; bh=Eac8/OwYQGHobnX6WiSq/aJtrjmz4yFNIw+ihpNACXI=; b=km3ieo60yZ9M3U/H4KSi5SXBBnaowBJBXAikfgfALFLekQIi4fPunEN8yLwvPKUPGI UncdIvCzNKkeE6uZ+C2ZtwcDJ5MpDg3JCZhhcG2i6/xumsBTJzERl1xzQT0c5zVHSKoC lIpkpSCy2wInvGaneoYfeQrnK5k5r/RZ0jx7KLolAINkoc2MA1LMMFnlMHeTqo9l4TmN YHWGn7WNsJBKJdr5NuaavQklayJ/tc4qpikivIqG4bZBl89wfyO18FO3tAIxz0hYTEW7 NUufEoEcQuBCtnykfPnAB1v8AigyuDMlmj6wWLkUzydFo6Crg4TwwGtg1bpLdRvi0qMx +YKg== X-Gm-Message-State: AOAM533GJIzdcXAo81928bkxIuhJR4tRUPScb9gQwFGbIYx6+kP1nVxF oxQCKgEpn5+9HFeqjovF9EcN4AxOhaE= X-Google-Smtp-Source: ABdhPJydfjVGiFHk6L4mp0aI56JtapKziB5Wu/mkJIXxIj8X7qSG4NderC8fMtjzIFlrhR3umhiFRg== X-Received: by 2002:adf:a59a:: with SMTP id g26mr6080097wrc.262.1642119823431; Thu, 13 Jan 2022 16:23:43 -0800 (PST) Received: from ?IPV6:2a01:4b00:8697:de00:607c:1dff:fe2e:2452? ([2a01:4b00:8697:de00:607c:1dff:fe2e:2452]) by smtp.gmail.com with ESMTPSA id o13sm4726706wrc.111.2022.01.13.16.23.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Jan 2022 16:23:42 -0800 (PST) Content-Type: multipart/mixed; boundary="------------oxcdymuqZIqo6orjfYSjx9Eq" Message-ID: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> Date: Fri, 14 Jan 2022 00:23:42 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-GB To: bug-gnu-emacs@gnu.org From: Sergey Vinokurov Subject: [PATCH] unify reads from local_var_alist X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::434 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::434; envelope-from=serg.foo@gmail.com; helo=mail-wr1-x434.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This is a multi-part message in MIME format. --------------oxcdymuqZIqo6orjfYSjx9Eq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, I've noticed that local_var_alist field of the buffer structure is accessed inconsistently. Sometimes it's Fassoc, sometimes it's Fassq and other times it's assq_no_quit and even an explicit loop. I think it's safe to unify all the accesses via assq_no_quit since it's an internaly maintained alist that definitely has no cycles and elements are cons cells with symbol as their car. Sergey --------------oxcdymuqZIqo6orjfYSjx9Eq Content-Type: text/x-patch; charset=UTF-8; name="0001-Unify-getting-of-values-from-local_var_alist.patch" Content-Disposition: attachment; filename="0001-Unify-getting-of-values-from-local_var_alist.patch" Content-Transfer-Encoding: base64 RnJvbSAyZWQyY2JiOTFkNWUwOTYxNWFkNjYxMDgxMDAxNDE5OGEyNjlkNTM5IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBTZXJnZXkgVmlub2t1cm92IDxzZXJnLmZvb0BnbWFp bC5jb20+CkRhdGU6IEZyaSwgMTQgSmFuIDIwMjIgMDA6MTY6MTkgKzAwMDAKU3ViamVjdDog W1BBVENIXSBVbmlmeSBnZXR0aW5nIG9mIHZhbHVlcyBmcm9tIGxvY2FsX3Zhcl9hbGlzdAoK LS0tCiBzcmMvYnVmZmVyLmMgfCAgMiArLQogc3JjL2RhdGEuYyAgIHwgMTYgKysrKysrLS0t LS0tLS0tLQogMiBmaWxlcyBjaGFuZ2VkLCA3IGluc2VydGlvbnMoKyksIDExIGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL3NyYy9idWZmZXIuYyBiL3NyYy9idWZmZXIuYwppbmRleCAx MGFjOTE5MTVjLi5hMzA5MTAxNWQ5IDEwMDY0NAotLS0gYS9zcmMvYnVmZmVyLmMKKysrIGIv c3JjL2J1ZmZlci5jCkBAIC0xMjQ3LDcgKzEyNDcsNyBAQCBidWZmZXJfbG9jYWxfdmFsdWUg KExpc3BfT2JqZWN0IHZhcmlhYmxlLCBMaXNwX09iamVjdCBidWZmZXIpCiAgICAgICB7IC8q IExvb2sgaW4gbG9jYWxfdmFyX2FsaXN0LiAgKi8KIAlzdHJ1Y3QgTGlzcF9CdWZmZXJfTG9j YWxfVmFsdWUgKmJsdiA9IFNZTUJPTF9CTFYgKHN5bSk7CiAJWFNFVFNZTUJPTCAodmFyaWFi bGUsIHN5bSk7IC8qIFVwZGF0ZSBJbiBjYXNlIG9mIGFsaWFzaW5nLiAgKi8KLQlyZXN1bHQg PSBGYXNzb2MgKHZhcmlhYmxlLCBCVkFSIChidWYsIGxvY2FsX3Zhcl9hbGlzdCksIFFuaWwp OworCXJlc3VsdCA9IGFzc3Ffbm9fcXVpdCAodmFyaWFibGUsIEJWQVIgKGJ1ZiwgbG9jYWxf dmFyX2FsaXN0KSk7CiAJaWYgKCFOSUxQIChyZXN1bHQpKQogCSAgewogCSAgICBpZiAoYmx2 LT5md2QuZndkcHRyKQpkaWZmIC0tZ2l0IGEvc3JjL2RhdGEuYyBiL3NyYy9kYXRhLmMKaW5k ZXggNWQwNzkwNjkyYi4uZjI4N2MzOGZjZCAxMDA2NDQKLS0tIGEvc3JjL2RhdGEuYworKysg Yi9zcmMvZGF0YS5jCkBAIC0yMTAzLDcgKzIxMDMsNyBAQCBERUZVTiAoIm1ha2UtbG9jYWwt dmFyaWFibGUiLCBGbWFrZV9sb2NhbF92YXJpYWJsZSwgU21ha2VfbG9jYWxfdmFyaWFibGUs CiAKICAgLyogTWFrZSBzdXJlIHRoaXMgYnVmZmVyIGhhcyBpdHMgb3duIHZhbHVlIG9mIHN5 bWJvbC4gICovCiAgIFhTRVRTWU1CT0wgKHZhcmlhYmxlLCBzeW0pOwkvKiBVcGRhdGUgaW4g Y2FzZSBvZiBhbGlhc2luZy4gICovCi0gIHRlbSA9IEZhc3NxICh2YXJpYWJsZSwgQlZBUiAo Y3VycmVudF9idWZmZXIsIGxvY2FsX3Zhcl9hbGlzdCkpOworICB0ZW0gPSBhc3NxX25vX3F1 aXQgKHZhcmlhYmxlLCBCVkFSIChjdXJyZW50X2J1ZmZlciwgbG9jYWxfdmFyX2FsaXN0KSk7 CiAgIGlmIChOSUxQICh0ZW0pKQogICAgIHsKICAgICAgIGlmIChsZXRfc2hhZG93c19idWZm ZXJfYmluZGluZ19wIChzeW0pKQpAQCAtMjE4Myw3ICsyMTgzLDcgQEAgREVGVU4gKCJraWxs LWxvY2FsLXZhcmlhYmxlIiwgRmtpbGxfbG9jYWxfdmFyaWFibGUsIFNraWxsX2xvY2FsX3Zh cmlhYmxlLAogCiAgIC8qIEdldCByaWQgb2YgdGhpcyBidWZmZXIncyBhbGlzdCBlbGVtZW50 LCBpZiBhbnkuICAqLwogICBYU0VUU1lNQk9MICh2YXJpYWJsZSwgc3ltKTsJLyogUHJvcGFn YXRlIHZhcmlhYmxlIGluZGlyZWN0aW9uLiAgKi8KLSAgdGVtID0gRmFzc3EgKHZhcmlhYmxl LCBCVkFSIChjdXJyZW50X2J1ZmZlciwgbG9jYWxfdmFyX2FsaXN0KSk7CisgIHRlbSA9IGFz c3Ffbm9fcXVpdCAodmFyaWFibGUsIEJWQVIgKGN1cnJlbnRfYnVmZmVyLCBsb2NhbF92YXJf YWxpc3QpKTsKICAgaWYgKCFOSUxQICh0ZW0pKQogICAgIGJzZXRfbG9jYWxfdmFyX2FsaXN0 CiAgICAgICAoY3VycmVudF9idWZmZXIsCkBAIC0yMjI0LDcgKzIyMjQsNyBAQCBERUZVTiAo ImxvY2FsLXZhcmlhYmxlLXAiLCBGbG9jYWxfdmFyaWFibGVfcCwgU2xvY2FsX3ZhcmlhYmxl X3AsCiAgICAgY2FzZSBTWU1CT0xfUExBSU5WQUw6IHJldHVybiBRbmlsOwogICAgIGNhc2Ug U1lNQk9MX0xPQ0FMSVpFRDoKICAgICAgIHsKLQlMaXNwX09iamVjdCB0YWlsLCBlbHQsIHRt cDsKKwlMaXNwX09iamVjdCB0bXA7CiAJc3RydWN0IExpc3BfQnVmZmVyX0xvY2FsX1ZhbHVl ICpibHYgPSBTWU1CT0xfQkxWIChzeW0pOwogCVhTRVRCVUZGRVIgKHRtcCwgYnVmKTsKIAlY U0VUU1lNQk9MICh2YXJpYWJsZSwgc3ltKTsgLyogVXBkYXRlIGluIGNhc2Ugb2YgYWxpYXNp bmcuICAqLwpAQCAtMjIzMiwxMyArMjIzMiw5IEBAIERFRlVOICgibG9jYWwtdmFyaWFibGUt cCIsIEZsb2NhbF92YXJpYWJsZV9wLCBTbG9jYWxfdmFyaWFibGVfcCwKIAlpZiAoRVEgKGJs di0+d2hlcmUsIHRtcCkpIC8qIFRoZSBiaW5kaW5nIGlzIGFscmVhZHkgbG9hZGVkLiAgKi8K IAkgIHJldHVybiBibHZfZm91bmQgKGJsdikgPyBRdCA6IFFuaWw7CiAJZWxzZQotCSAgZm9y ICh0YWlsID0gQlZBUiAoYnVmLCBsb2NhbF92YXJfYWxpc3QpOyBDT05TUCAodGFpbCk7IHRh aWwgPSBYQ0RSICh0YWlsKSkKLQkgICAgewotCSAgICAgIGVsdCA9IFhDQVIgKHRhaWwpOwot CSAgICAgIGlmIChFUSAodmFyaWFibGUsIFhDQVIgKGVsdCkpKQotCQlyZXR1cm4gUXQ7Ci0J ICAgIH0KLQlyZXR1cm4gUW5pbDsKKwkgIHJldHVybiBOSUxQIChhc3NxX25vX3F1aXQgKHZh cmlhYmxlLCBCVkFSIChidWYsIGxvY2FsX3Zhcl9hbGlzdCkpKQorCSAgICA/IFFuaWwKKwkg ICAgOiBRdDsKICAgICAgIH0KICAgICBjYXNlIFNZTUJPTF9GT1JXQVJERUQ6CiAgICAgICB7 Ci0tIAoyLjM0LjEKCg== --------------oxcdymuqZIqo6orjfYSjx9Eq-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 14 02:50:01 2022 Received: (at 53242) by debbugs.gnu.org; 14 Jan 2022 07:50:01 +0000 Received: from localhost ([127.0.0.1]:35330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8HLV-0001GZ-1I for submit@debbugs.gnu.org; Fri, 14 Jan 2022 02:50:01 -0500 Received: from quimby.gnus.org ([95.216.78.240]:34180) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8HLS-0001GJ-NU for 53242@debbugs.gnu.org; Fri, 14 Jan 2022 02:49:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=eE7i7ldBge7GQiYiZDsUB59mu1m6SdoFAYrJSrkDyao=; b=eG6eTkj50wsOrOi7GwW10PmOzo keh7WUUZBuiR2/N8IFMeNW99BMtIy/4i96X3WaWCrnfIgdM4DtkZ+UQa/AHRzonUUBlbrebfsQJAD Hxuty70eEafM/nFEV3t6GQqvTb474pIgdebmuvDTumJoSXyIa7UaTURVcUNTSgB22JUs=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n8HLJ-0001P9-FO; Fri, 14 Jan 2022 08:49:51 +0100 From: Lars Ingebrigtsen To: Sergey Vinokurov Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> X-Now-Playing: Various's _I Wanna Be Kate: The Songs of Kate Bush_: "Love And Anger (2020 Remaster)" Date: Fri, 14 Jan 2022 08:49:48 +0100 In-Reply-To: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> (Sergey Vinokurov's message of "Fri, 14 Jan 2022 00:23:42 +0000") Message-ID: <87leziu57n.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Sergey Vinokurov writes: > I've noticed that local_var_alist field of the buffer structure is > accessed inconsistently. Sometimes it's Fassoc, sometimes it's Fassq > and other times it's assq_no_quit and even an explicit loo [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53242 Cc: 53242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Sergey Vinokurov writes: > I've noticed that local_var_alist field of the buffer structure is > accessed inconsistently. Sometimes it's Fassoc, sometimes it's Fassq > and other times it's assq_no_quit and even an explicit loop. > > I think it's safe to unify all the accesses via assq_no_quit since > it's an internaly maintained alist that definitely has no cycles and > elements are cons cells with symbol as their car. Makes sense to me, so I've now applied your patch to Emacs 29 (and added a ChangeLog-format commit message). -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 14 02:50:05 2022 Received: (at control) by debbugs.gnu.org; 14 Jan 2022 07:50:05 +0000 Received: from localhost ([127.0.0.1]:35334 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8HLZ-0001HJ-9p for submit@debbugs.gnu.org; Fri, 14 Jan 2022 02:50:05 -0500 Received: from quimby.gnus.org ([95.216.78.240]:34194) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8HLX-0001GQ-4a for control@debbugs.gnu.org; Fri, 14 Jan 2022 02:50:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=5vGbd/ZDR6LAGmUeT8jTe7pt1uL4gvr0+Ugwm0f4OUY=; b=cV4zwZd0NzQZSnkI6KlvNmB9ji MeIcWmFMqdMzVfdZWkef+L3EXppu6O9v9ssNByGffOaDQ0IMY4GWEOsxQ2m/jA21pNoA8+bSnGPeH bEt/7lcohp4NB/VKehOsapTdhaZu+WlZeyC2xbA0OqUW8JMLeNnZUYUQBBULzjXGLI1M=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n8HLP-0001PK-2b for control@debbugs.gnu.org; Fri, 14 Jan 2022 08:49:57 +0100 Date: Fri, 14 Jan 2022 08:49:54 +0100 Message-Id: <87k0f2u57h.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #53242 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 53242 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 53242 29.1 quit From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 14 03:09:07 2022 Received: (at 53242) by debbugs.gnu.org; 14 Jan 2022 08:09:07 +0000 Received: from localhost ([127.0.0.1]:35393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8Hdz-000472-H2 for submit@debbugs.gnu.org; Fri, 14 Jan 2022 03:09:07 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60284) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8Hdu-00046S-6U for 53242@debbugs.gnu.org; Fri, 14 Jan 2022 03:09:06 -0500 Received: from [2001:470:142:3::e] (port=36024 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 1n8Hdo-0000u4-WE; Fri, 14 Jan 2022 03:08: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=Z3jA4VYJxvCBUPZk7hZ/bwyZfFGUHUNpxbPcfUhbqPM=; b=r3xGL9YI+bjL L8SaoEv/e4D+DkbmRxMdAkqaS+HdeWYXeL8j+pHdkdUbYcnZeRCe640Zc+wIdrRNyy+EBzJ63oG6t NDHEdIiOKtku7iCscfoxyTwBXPiAaYVGQvc67/AJuxabiIb2QgtNnDigWbRQS7DAlxGCgKHEEBDcs LC2GeEJdfhrg+mYBCJ+1u7886cdV2uPIyECj3bjUKLXeiZ8RSzNY8nFRFMdzwVutgw0B2VNZ7c6Ow SeljLKUUkd16kEUTEbqsAlBGYzMr7gzLEuLjT4NLnvCi0jl1aPLeYuqIOKkQN0gn4f9aFPRWxD8Vw qJzPVhaXb1KdRXiRcCiJGA==; Received: from [87.69.77.57] (port=2091 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 1n8Hdh-0005DV-QC; Fri, 14 Jan 2022 03:08:55 -0500 Date: Fri, 14 Jan 2022 10:08:49 +0200 Message-Id: <83zgny20z2.fsf@gnu.org> From: Eli Zaretskii To: Sergey Vinokurov In-Reply-To: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> (message from Sergey Vinokurov on Fri, 14 Jan 2022 00:23:42 +0000) Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53242 Cc: 53242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 14 Jan 2022 00:23:42 +0000 > From: Sergey Vinokurov > > I've noticed that local_var_alist field of the buffer structure is > accessed inconsistently. Sometimes it's Fassoc, sometimes it's Fassq and > other times it's assq_no_quit and even an explicit loop. > > I think it's safe to unify all the accesses via assq_no_quit since it's > an internaly maintained alist that definitely has no cycles and elements > are cons cells with symbol as their car. 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? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 14 03:33:24 2022 Received: (at 53242) by debbugs.gnu.org; 14 Jan 2022 08:33:24 +0000 Received: from localhost ([127.0.0.1]:35484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8I1U-0000ud-0t for submit@debbugs.gnu.org; Fri, 14 Jan 2022 03:33:24 -0500 Received: from quimby.gnus.org ([95.216.78.240]:34830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8I1S-0000uN-09 for 53242@debbugs.gnu.org; Fri, 14 Jan 2022 03:33:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=SFRz+ytlW4FXZpyKcADPZH/LfxTDo7/6TXYeVAmA4+0=; b=GdYltbgiRAwlqsP7iXrAlc4Owt RwpBqTe05PDIUogzTkpxHdmGer1F7hefLFkEGGMPlTabB0y+Gnf3fYau+yeMiRFveHiIurUtrbKO9 gosCxCMcLrk/FFOSPh9JZb+JCysWFrWMpJpn/w1o3pDQvZmlV2KeXwx4dCL1AbUVlQbw=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n8I1I-0001kD-U0; Fri, 14 Jan 2022 09:33:15 +0100 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> <83zgny20z2.fsf@gnu.org> X-Now-Playing: Various's _I Wanna Be Kate: The Songs of Kate Bush_: "Nocturn (feat. Carol Keogh)" Date: Fri, 14 Jan 2022 09:33:11 +0100 In-Reply-To: <83zgny20z2.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Jan 2022 10:08:49 +0200") Message-ID: <87fspqra2g.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > 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? There was already one usage of assq_no_quit on the variable, so the change seemed safe to me. If it turns out that it's not, all the usages should be changed to Fassq. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53242 Cc: Sergey Vinokurov , 53242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > 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? There was already one usage of assq_no_quit on the variable, so the change seemed safe to me. If it turns out that it's not, all the usages should be changed to Fassq. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 14 13:37:57 2022 Received: (at 53242) by debbugs.gnu.org; 14 Jan 2022 18:37:57 +0000 Received: from localhost ([127.0.0.1]:38123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8RSX-0001Bp-7l for submit@debbugs.gnu.org; Fri, 14 Jan 2022 13:37:57 -0500 Received: from mail-wm1-f53.google.com ([209.85.128.53]:53919) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8RST-0001BZ-6J for 53242@debbugs.gnu.org; Fri, 14 Jan 2022 13:37:55 -0500 Received: by mail-wm1-f53.google.com with SMTP id l4so7681684wmq.3 for <53242@debbugs.gnu.org>; Fri, 14 Jan 2022 10:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=Q74F7xBkBghQEVkFNS2AEGaBQNJYQAEByMFzIyRl4+4=; b=JktLOMOflytVy4hEonU7A/zDzqqhciRIuAWC+aK6I0d42XJ9vxAIw+rvXCANA+wpLo rbUFocB7zYyGb1orRzjnEKc7KW4tPRn6IfA/gSGcnytHtxFLHrR+bxZOY74SLj29p+jr 9qEH/0M9jhw1OP8hdthMCjjmJvdJfxXEwuE3KMt5l3WzIBl/iM9yH7T7ZJJQrucaYnx9 1/RzYk/+m/o7yW/7QUJXlpVtwSQ4ZtyDoU1qxEOb3wpKm56spW13frJCy+JLeLwrtcFY LsVffiLCxwzNAxNEK4UG0SvymXDIevI1PfsJKtnh+3r8SEJxkIAPmVxb6oZ3Ldabs43p JIgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Q74F7xBkBghQEVkFNS2AEGaBQNJYQAEByMFzIyRl4+4=; b=7omUgKdEO+ZRQYmIib7yeWwSEKke4p7/QehFDOMPEhLGAE93/+xtgJ4ExWZd17/Pun 2Zk8kujGCBJJsnV8BD8Gv8LaZ51gYdGfZLUyCoSI/FXSxmAGRNwxTxfDdsFpUGCJjcPt 0tW7SvwoHv0sh23psPs3nd5KnDqNwLpTrmwGYV60lC4zXQanV0S0/SdFtRMka1tiyUMm hXDjvvvNMMy4ch//7PU+ihJsRd9xjxXqSUSCI4vOSlxt+z61OQ4795ZIRk09bU6a2HOG CUiz8a+DIPh/iZZRv9UWnibxAb2iWwXLY5hG/wsu1+XKisogXnmGrk7dJkvp8QCsmBT0 ZV0Q== X-Gm-Message-State: AOAM531a1JunQsScFq+8720fdW6c+OnXQAaEG5v5AVRzgdzHRk58ZDLs 027y5oA5lQnv7BidBKQiQn8= X-Google-Smtp-Source: ABdhPJxps6qUWx/ZZY/W8ZkWyXlotkFyqrynACXc9W0TWYI5pbbWmy5sKD1Yhn3JeL9LTEJ6CgrxfQ== X-Received: by 2002:a5d:634e:: with SMTP id b14mr9698859wrw.105.1642185467180; Fri, 14 Jan 2022 10:37:47 -0800 (PST) Received: from [192.168.1.106] ([152.37.93.248]) by smtp.gmail.com with ESMTPSA id g6sm6383163wri.80.2022.01.14.10.37.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jan 2022 10:37:46 -0800 (PST) Message-ID: <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> Date: Fri, 14 Jan 2022 18:37:45 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist Content-Language: en-GB To: Eli Zaretskii References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> <83zgny20z2.fsf@gnu.org> From: Sergey Vinokurov In-Reply-To: <83zgny20z2.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 53242 Cc: 53242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On 14/01/2022 08:08, Eli Zaretskii wrote: >> Date: Fri, 14 Jan 2022 00:23:42 +0000 >> From: Sergey Vinokurov >> >> I've noticed that local_var_alist field of the buffer structure is >> accessed inconsistently. Sometimes it's Fassoc, sometimes it's Fassq and >> other times it's assq_no_quit and even an explicit loop. >> >> I think it's safe to unify all the accesses via assq_no_quit since it's >> an internaly maintained alist that definitely has no cycles and elements >> are cons cells with symbol as their car. > > 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. 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. Perhaps if list gets really long it could be beneficial to use some other data structure, perhaps a hash table, instead. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 14 14:02:06 2022 Received: (at 53242) by debbugs.gnu.org; 14 Jan 2022 19:02:06 +0000 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 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 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==; 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 Date: Fri, 14 Jan 2022 21:01:49 +0200 Message-Id: <83ilum16qq.fsf@gnu.org> From: Eli Zaretskii To: Sergey Vinokurov In-Reply-To: <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> (message from Sergey Vinokurov on Fri, 14 Jan 2022 18:37:45 +0000) Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> <83zgny20z2.fsf@gnu.org> <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53242 Cc: 53242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 14 16:01:56 2022 Received: (at 53242) by debbugs.gnu.org; 14 Jan 2022 21:01:56 +0000 Received: from localhost ([127.0.0.1]:38352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8Ths-0005JJ-6Z for submit@debbugs.gnu.org; Fri, 14 Jan 2022 16:01:56 -0500 Received: from mail-wm1-f43.google.com ([209.85.128.43]:38731) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8Thp-0005Iy-0T for 53242@debbugs.gnu.org; Fri, 14 Jan 2022 16:01:54 -0500 Received: by mail-wm1-f43.google.com with SMTP id p1-20020a1c7401000000b00345c2d068bdso9383104wmc.3 for <53242@debbugs.gnu.org>; Fri, 14 Jan 2022 13:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=OIvrhf6IE1/wOjyf7baP7UK6yF6tso+yJGosVcHi+pg=; b=TaxnTY6hgrUPnbJOXxv+kW/pYVmmQ6GB0nEz+QvZBxU+KH5hg9w/YE+aQFuLKZrZGN 4QhfbiHKLGDxo+vGGlhxoXAK9QKngZjnNUjoSTk2+EDMGiFrdLCZ7P/XAn4XwpUD9BWF Kj8ZTuCsYJHBcg1xq8LQKGa8730JlppIgl88GroD9aKhSOc3sqpxppwZdnVlFixFXdKQ J46chJfE0V6BP9v1kuwpR8HBBEHN6fsLkTVo/33+bk+UTySazgRv2K9Ljf5iDfCToDka RyU3JLmQvbtHJxiiWB7w3/t8SGGJ4xkg08tPji78klDyKU1rQM+57ahF9yQzv/qyQdTe foxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=OIvrhf6IE1/wOjyf7baP7UK6yF6tso+yJGosVcHi+pg=; b=MR+p8XKfhCLdQCneZDEbQH3RApoibjP4HDgSrkP+bzjjjn3yomsSGxGsJojqi7S3Y2 MfhFT3S2gv4gPpjrAmOF5XnRXZjECvyBAvTuMaoxM/T326muVlDi7jcGD30GTMe/pJoH 7BMmpwHiMlTI84OmCz9pSxSbsgFf80yfFtFd53wSjwbu5/BTf8RWgSm3LX8P3flugb6m vSOnWFWnntsjaTqlKWSbKANNRnYV4x6KfeZpVsnDEoq5mEfVmRmqxxi7GwMNTSdYW1Sl pAxZDaLYubNgyD6MTn6PyDsyoqjo23/YVw7g2GsXC36nawfp4nafrPJUkakvhz9bA5F6 2WWg== X-Gm-Message-State: AOAM533f7CVCpeuFWmDhaNWXHv3pBUmUtbTEX4EyNpp3G3ilbAbXexEl 2vrWXPDodKoQdkB6w9ZhtqgsU/ehU34= X-Google-Smtp-Source: ABdhPJxvKh8x8KerEyMFNXQgP1bo+nmCrxCCNnK3V4Ef0e9RrG2tR24SM6tRDgNpIiaM5Sd86PdIfg== X-Received: by 2002:a5d:69ce:: with SMTP id s14mr8506836wrw.427.1642194107277; Fri, 14 Jan 2022 13:01:47 -0800 (PST) Received: from ?IPV6:2a01:4b00:8697:de00:607c:1dff:fe2e:2452? ([2a01:4b00:8697:de00:607c:1dff:fe2e:2452]) by smtp.gmail.com with ESMTPSA id o11sm12173564wmq.15.2022.01.14.13.01.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jan 2022 13:01:46 -0800 (PST) Message-ID: <1e4edf7d-7f9c-ef56-7870-6f0f3567a40d@gmail.com> Date: Fri, 14 Jan 2022 21:01:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist Content-Language: en-GB To: Eli Zaretskii References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> <83zgny20z2.fsf@gnu.org> <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> <83ilum16qq.fsf@gnu.org> From: Sergey Vinokurov In-Reply-To: <83ilum16qq.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 53242 Cc: 53242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On 14/01/2022 19:01, Eli Zaretskii wrote: >> 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. My reasoning is as follows: consider what is stored in the local_var_alist. It's only for buffer-local variables, no other entries should get into the list. Thus the size of this list is directly proportional to the number of local variables in current buffer. How many local variable bindings could be defined at the same time? Any amount, really. There can be no local variables or, in pathological case, there can be any number of them (consider a program executing `(dolist (i N) (set (make-local-variable (intern (format "foo%s" i))) i))` with arbitrary N). I argue that something's wrong if there are so many local variables defined that lookups into the local_var_alist would cause significant delays. The lookups will happen each time a buffer-local variable is read or written to in elisp. If these lookups take a long time then any elisp working with these variables become slow. My argument is that at this point we don't care whether user is able to interrupt basic operations of reading and writing buffer-local variables. Even if we use Fassq and the user could interrupt, nothing is gained in my opinion - any command that involves reading or writing buffer-local variables will still remain slow. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 15 02:32:26 2022 Received: (at 53242) by debbugs.gnu.org; 15 Jan 2022 07:32:26 +0000 Received: from localhost ([127.0.0.1]:38838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8dY2-0004Et-HU for submit@debbugs.gnu.org; Sat, 15 Jan 2022 02:32:26 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58274) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8dY1-0004Eg-OB for 53242@debbugs.gnu.org; Sat, 15 Jan 2022 02:32:26 -0500 Received: from [2001:470:142:3::e] (port=49678 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 1n8dXw-0001G8-FO; Sat, 15 Jan 2022 02:32:20 -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=Ekc3Z7dSS4WwD+SlwNFx+0qFoV7grxHN2iNgW2idXC0=; b=rpVETwmP8iOU z2x79ouhlgIXve10bBAHccr2CrgH9WKxVahOBhdGCS4ieEJxtsJOuzFaAJmlgWzMrM2aTZ2hh8/I2 Rse/1Yv5TWRihAGbtVUmMc2AM81cvZq47glyFqWJLraM/b5bifN5Hq6BA9g3TwlLvtD1OdYuyWpgo dpLbKeGr4ReW/QKYSPlXJNBCTe6sm9dlnneVrOZOkryAuPd1isZY1MWGqNx0YZhOJPnFEcGQ9ixmu d7KDTPKKnZzYnyIirp9rc5O2dYQUaGZR/M+wbWqAphuEvBTx1TI1aOC/vc4Pmc1QZgg6K1aJssv6M cWSj4jMMDYeq6gUvcsaQgQ==; Received: from [87.69.77.57] (port=4441 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 1n8dXw-0001dx-HO; Sat, 15 Jan 2022 02:32:20 -0500 Date: Sat, 15 Jan 2022 09:32:04 +0200 Message-Id: <83ee591mkr.fsf@gnu.org> From: Eli Zaretskii To: Sergey Vinokurov In-Reply-To: <1e4edf7d-7f9c-ef56-7870-6f0f3567a40d@gmail.com> (message from Sergey Vinokurov on Fri, 14 Jan 2022 21:01:46 +0000) Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> <83zgny20z2.fsf@gnu.org> <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> <83ilum16qq.fsf@gnu.org> <1e4edf7d-7f9c-ef56-7870-6f0f3567a40d@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53242 Cc: 53242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 14 Jan 2022 21:01:46 +0000 > Cc: 53242@debbugs.gnu.org > From: Sergey Vinokurov > > I argue that something's wrong if there are so many local variables > defined that lookups into the local_var_alist would cause > significant delays. I agree that something is wrong, in the sense that the implementation of some feature(s) should probably be rethought. But that's not the point I'm trying to make. The point I'm trying to make is that formerly, the user could interrupt such a long search, and now he/she cannot. The user is usually not the one to "blame" for the length of the list. With the previous code, the user had a "fire escape". > My argument is that at this point we don't care whether user is able > to interrupt basic operations of reading and writing buffer-local > variables. "We" might not care, but the user could very much care. We in effect locked the users without no way to handle these situations. > Even if we use Fassq and the user could interrupt, nothing is gained > in my opinion - any command that involves reading or writing > buffer-local variables will still remain slow. The commands will remain slow, but the users could stop Emacs from wasting their time. Now they cannot. Saying that "we don't care" means we don't care about our users, which is certainly not true. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 15 06:41:13 2022 Received: (at 53242) by debbugs.gnu.org; 15 Jan 2022 11:41:13 +0000 Received: from localhost ([127.0.0.1]:39266 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8hQn-00061Q-JJ for submit@debbugs.gnu.org; Sat, 15 Jan 2022 06:41:13 -0500 Received: from mail-wm1-f53.google.com ([209.85.128.53]:38424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8hQj-000616-B9 for 53242@debbugs.gnu.org; Sat, 15 Jan 2022 06:41:12 -0500 Received: by mail-wm1-f53.google.com with SMTP id p1-20020a1c7401000000b00345c2d068bdso12469305wmc.3 for <53242@debbugs.gnu.org>; Sat, 15 Jan 2022 03:41:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=A/8UoCLZHV+imTsS8PkMG6Utqkx/YOzEnVLilN8p6i4=; b=TL43YOd2s6LRkCiAFxpFjNeZ+EL/18+t9W4Enpn9UUnlwMUNMQImE2Ci68fAlhYgE3 IyLUlvzH89SDrTQODbGkhO08/N0gdkSIbWSPJVYh1t4Re+EzgKvUOkXPlru1wzdkxkPA GZRTm2ujAtlX/z94oF7wspF48F8MOv+0FAG6Js112C3IUYyrDnXQiyHXQmLHLaCRlssN c7EPrNRLvQK3pRTe+jA51WgDoW9oG0jNap5EvGUY2IAGhgVNZhy5CzKTfmmg/vuUtyqp 2Gr8IUp668cKmI4BQ+yukoDpC+lQKdoA75W/AmfaRQkc9IPFgGzR576SIWoTnr5uefOs fX8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=A/8UoCLZHV+imTsS8PkMG6Utqkx/YOzEnVLilN8p6i4=; b=U3UBvPMjLdpmpFzyFKYNjJ2lrybNh7ztnDBTS1dnDe5ARU4MVjWj1bi92Qn4jHJSqC JxvjeP1wRbFrUvXIFJlmOlvV5s4C56xNKZC9/kl2U4XhBDt2J6a35OZszpxmK/4eWLf9 jAZ+IUbqCTrU3+L3w9TTCzioUk6aKJKk0fl9mNimsbKr4I4DGD7jaZFAuiU4lOwjl24C 5LTBXFtx0fg/Ix/QjSHJDuc6i+EWFpDbFtxoRXaJeiipNQp+RtoNnnja0waGICIib16B PCLJgydXU5w5Ftk44O2HhAvxRJ0rIaASdGd2G132e67WJ0sPtDEic3KEj8T6Q2ICLVFl YmVQ== X-Gm-Message-State: AOAM530iRUyIyFrzPmxvM3S/ykmOPJyg4G9pf/udgdOkxgAaSmf44H5V 5ybRqLI477QI65tOHox1ERWz6aNSgAY= X-Google-Smtp-Source: ABdhPJxrawESBpfLVEKgC21PTI19wg0uDqzC4Kt3n/EXiLWby7gWD7nQ3KrIkpO2Ye0YVcWhlrsDIg== X-Received: by 2002:a5d:4f85:: with SMTP id d5mr11993593wru.51.1642246863701; Sat, 15 Jan 2022 03:41:03 -0800 (PST) Received: from ?IPV6:2a01:4b00:8697:de00:607c:1dff:fe2e:2452? ([2a01:4b00:8697:de00:607c:1dff:fe2e:2452]) by smtp.gmail.com with ESMTPSA id m39sm13569022wms.33.2022.01.15.03.41.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 Jan 2022 03:41:03 -0800 (PST) Message-ID: <15fa68fa-2bb2-eaf4-885b-abdff1e3f61f@gmail.com> Date: Sat, 15 Jan 2022 11:41:02 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist Content-Language: en-GB To: Eli Zaretskii References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> <83zgny20z2.fsf@gnu.org> <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> <83ilum16qq.fsf@gnu.org> <1e4edf7d-7f9c-ef56-7870-6f0f3567a40d@gmail.com> <83ee591mkr.fsf@gnu.org> From: Sergey Vinokurov In-Reply-To: <83ee591mkr.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 53242 Cc: 53242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On 15/01/2022 07:32, Eli Zaretskii wrote: >> My argument is that at this point we don't care whether user is able >> to interrupt basic operations of reading and writing buffer-local >> variables. > > "We" might not care, but the user could very much care. We in effect > locked the users without no way to handle these situations. > >> Even if we use Fassq and the user could interrupt, nothing is gained >> in my opinion - any command that involves reading or writing >> buffer-local variables will still remain slow. > > The commands will remain slow, but the users could stop Emacs from > wasting their time. Now they cannot. Saying that "we don't care" > means we don't care about our users, which is certainly not true. I agree with your position but see a more further-reaching conclusion. If there's a risk of the list being really long the Emacs can employ a different data structure, e.g. a hash table, to make reads and writes of variables fast regardless of the number of entries. In my opinion such a change would serve users even better as there would be no need to interrupt any slow operations because there would be none. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 15 11:02:58 2022 Received: (at 53242) by debbugs.gnu.org; 15 Jan 2022 16:02:58 +0000 Received: from localhost ([127.0.0.1]:41575 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8lW5-0005yu-KL for submit@debbugs.gnu.org; Sat, 15 Jan 2022 11:02:57 -0500 Received: from mail-ed1-f45.google.com ([209.85.208.45]:43826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8lW3-0005yf-Fd for 53242@debbugs.gnu.org; Sat, 15 Jan 2022 11:02:56 -0500 Received: by mail-ed1-f45.google.com with SMTP id m4so45908977edb.10 for <53242@debbugs.gnu.org>; Sat, 15 Jan 2022 08:02:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KKMT+jPhQyQuFnysY5KyDcl7CdcQVS4b9DtShY2BDJY=; b=SPaftS3NRn1SgeEfCrjXTF6qH2QOMevoHjuyA5g2wgrl+W1bON6dhbmVpgkLF0eE9f QleiPGJpp56FGR7ZbxeAd/Psm7WgKTkrQCKhnlpzZMOdr864yDmWkHUnJKFrv9CiGTMC ppRzJK4UUPAOkC5o6we1cisjv2x+xUkrBkQNT0TNltEdcvyMGRInBmqCp84rQkHa6NkB 29CjaVSfuAfB2ybrkvAE8sN6eBXNYOZv/AWs2Sr3nnGRryFNC2f22sKc4d8t6nPraBR8 z7Sperg+buaOTQkx+ofrn6OTX9BTGU9j/8aaFbih11qrqvTlFLZmLCFgm4xQQmbyy8GH 1+dw== X-Gm-Message-State: AOAM532RzoxT3ll2qWzyrwgqQqNAI5KnJaRp9CwG8/NcXsEel76fYSMi ynaW8utJrS+NxExU+7isFlVtpLJTOllctpEiNww= X-Google-Smtp-Source: ABdhPJwQTJTxQA4L0O/9w5O2GIYVmHWu+opqjMOVlAuVwprnMo4vwsRYukhVWp3zqeAuoG7jyMIgO4T6q3yGgh8Wsj4= X-Received: by 2002:a17:906:3798:: with SMTP id n24mr6202198ejc.448.1642262569709; Sat, 15 Jan 2022 08:02:49 -0800 (PST) MIME-Version: 1.0 References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> <83zgny20z2.fsf@gnu.org> <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> <83ilum16qq.fsf@gnu.org> <1e4edf7d-7f9c-ef56-7870-6f0f3567a40d@gmail.com> <83ee591mkr.fsf@gnu.org> <15fa68fa-2bb2-eaf4-885b-abdff1e3f61f@gmail.com> In-Reply-To: <15fa68fa-2bb2-eaf4-885b-abdff1e3f61f@gmail.com> From: Corwin Brust Date: Sat, 15 Jan 2022 10:02:31 -0600 Message-ID: Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist To: Sergey Vinokurov Content-Type: multipart/alternative; boundary="00000000000018748205d5a10d59" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 53242 Cc: Eli Zaretskii , 53242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) --00000000000018748205d5a10d59 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your work on Emacs, On Sat, Jan 15, 2022, 05:42 Sergey Vinokurov wrote: > On 15/01/2022 07:32, Eli Zaretskii wrote: > >> My argument is that at this point we don't care whether user is able > >> to interrupt basic operations of reading and writing buffer-local > >> variables. > This is my view also, fwiw. Please consider the case of a package developer who may be abusing buffer-local vars during experiments. It seems this will cause much more =E2=80=99oops, time to kill Emacs/grab a co= ffee'. I agree with your position but see a more further-reaching conclusion. > If there's a risk of the list being really long the Emacs can employ a > different data structure, e.g. a hash table, to make reads and writes of > variables fast regardless of the number of entries. In my opinion such a > change would serve users even better as there would be no need to > interrupt any slow operations because there would be none. > I tried to follow this conversation but it wasn't clear to me what out motive is for this change. I had understood we typically make (especially in the c sources) our changes to achieve specific, tangible improvement. Is that the case here? is the particularly oppressive 'tech debt'? In the latter case, does history reflect consideration wrt the original selections in each of the various cases we hereby change? Also (and especially if we must 'clean for the sake of cleanliness'), could we prefer the (seeming more conservative of UX) interruptable varient in this case? (Is that very costly? How costly and how have we measured that?= ) It would be comforting if sweeping changes could be accompanied by analysis of the impacted sources. (We clearly deliberately chose interruptable search in some cases and not others to date. Why?) Thanks so very much for Emacs! --00000000000018748205d5a10d59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your work on Emacs,

On Sat, Jan 15, 2022, 05= :42 Sergey Vinokurov <serg.foo@gma= il.com> wrote:
On 15/01/2022= 07:32, Eli Zaretskii wrote:
>> My argument is that at this point we don't care whether user i= s able
>> to interrupt basic operations of reading and writing buffer-local<= br> >> variables.

This is my view also, fwiw.=C2=A0 Please consider the ca= se of a package developer who may be abusing buffer-local vars during exper= iments.=C2=A0 It seems this will cause much more =E2=80=99oops, time to kil= l Emacs/grab a coffee'.


I agree with your position but see a more further-reaching c= onclusion.
If there's a risk of the list being really long the Emacs can employ a =
different data structure, e.g. a hash table, to make reads and writes of variables fast regardless of the number of entries. In my opinion such a change would serve users even better as there would be no need to
interrupt any slow operations because there would be none.
=


I tried to follow this conversation but it wasn't clear to m= e what out motive is for this change.

I had understood we typically make (especially in the c sourc= es) our changes to achieve specific, tangible improvement.=C2=A0 Is that th= e case here?=C2=A0 is the particularly oppressive 'tech debt'?=C2= =A0 In the latter case, does history reflect consideration wrt the original= selections in each of the various cases we hereby change?

Also (and especially if we must 'cle= an for the sake of cleanliness'), could we prefer the (seeming more con= servative of UX) interruptable varient in this case?=C2=A0 (Is that very co= stly? How costly and how have we measured that?)
It would be comforting if sweeping changes could b= e accompanied by analysis of the impacted sources.=C2=A0 (We clearly delibe= rately chose interruptable search in some cases and not others to date.=C2= =A0 Why?)

Thanks so very= much for Emacs!


--00000000000018748205d5a10d59-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 15 12:54:13 2022 Received: (at 53242) by debbugs.gnu.org; 15 Jan 2022 17:54:13 +0000 Received: from localhost ([127.0.0.1]:41685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8nFl-0002qU-17 for submit@debbugs.gnu.org; Sat, 15 Jan 2022 12:54:13 -0500 Received: from mail-wm1-f44.google.com ([209.85.128.44]:54115) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8nFh-0002qD-T3 for 53242@debbugs.gnu.org; Sat, 15 Jan 2022 12:54:11 -0500 Received: by mail-wm1-f44.google.com with SMTP id k5so3032051wmj.3 for <53242@debbugs.gnu.org>; Sat, 15 Jan 2022 09:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=VkrsI2GQkTLQy5S5YxfM0y7jaMFDTQq/xi8CwsuQROE=; b=P4fN8GHKfVqWdMykmb3W63fF8UPZ+e69jtmPT6sqJjXcvKu4ZNs9nZ8VeBvnfM80iP mtWhHM3N/tiJM/8xy+CK0pkklwkd/UDdP8r8ga1sp4sc+mQKNqkadimJCqT+4Ihd/wjb RJzROPjUkn6HTm6Cdod9qiXn46L4vNKB01uCCjiJ1xRQscVSXxSe9h+9jZye2AjFWVhJ llEVve565nNMlWQkBPfBSmKYpPHknrYtM1SIfNjjnGA2UkW8lBqY+1D15+wCukQrwZ1C 3L6rWlA3eftPL1EVFxPzLeWwETX7S1QLNoyh38WtgLa+xAqZyrhbQC1DLaheMXFUnlR/ +T4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=VkrsI2GQkTLQy5S5YxfM0y7jaMFDTQq/xi8CwsuQROE=; b=CBBHrKa6gwbjy3hPfb/xdPOF/ZI666UUZNfCPwKv3T5Cc++k/iZwxFk6OQBj3INrAP aWYIwWNwVEuma1KDpUhdM1PJcGB6dmkMlz7QNHECZL+0Lks3jdUonXqpy5FuFitpFEfl 7R8TapwKZwvKgG+qaLpUSyh5locXyAkRS/VcGUoakDawykH8GKjfdzYDtXtBszZvIXdH AM8PVlSSPqXl9jxO89JtDgM43Uk/vAKsUcHogwuNZaxnZf6V1TCDGvU+XHh8S0VhTaS+ WYGm5sQIUQ+K8cfOyXhuz8i5sh6352Ra/YVVduaaIxEFzqLpBnIrpKlfn3gY3B1Bk+2R QcHA== X-Gm-Message-State: AOAM5331JviqKjc+wmrtUx7nRLPM77BHFj7KgEwW13I0uBbcLYF4tK6A sXGZocGZOA4cx2D55wGzC30= X-Google-Smtp-Source: ABdhPJwJQH4s5HWqu4vQdXnWN6on245rzaYVjd9tnO9643DBPHkc7/ClOGYjaytPQTdPoGfXSsV+EQ== X-Received: by 2002:a05:600c:4e4b:: with SMTP id e11mr13075390wmq.28.1642269243762; Sat, 15 Jan 2022 09:54:03 -0800 (PST) Received: from ?IPV6:2a01:4b00:8697:de00:607c:1dff:fe2e:2452? ([2a01:4b00:8697:de00:607c:1dff:fe2e:2452]) by smtp.gmail.com with ESMTPSA id p18sm8227942wma.40.2022.01.15.09.54.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 15 Jan 2022 09:54:02 -0800 (PST) Message-ID: <6868768b-ed98-930f-0d50-74d961db4c0c@gmail.com> Date: Sat, 15 Jan 2022 17:54:02 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: bug#53242: [PATCH] unify reads from local_var_alist Content-Language: en-GB To: Corwin Brust References: <50d65dbc-f3d6-86fb-6a7c-9200a6525ec2@gmail.com> <83zgny20z2.fsf@gnu.org> <74db84b1-5433-dfb8-8ee3-9d86d8fc9be7@gmail.com> <83ilum16qq.fsf@gnu.org> <1e4edf7d-7f9c-ef56-7870-6f0f3567a40d@gmail.com> <83ee591mkr.fsf@gnu.org> <15fa68fa-2bb2-eaf4-885b-abdff1e3f61f@gmail.com> From: Sergey Vinokurov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.1 (-) X-Debbugs-Envelope-To: 53242 Cc: Eli Zaretskii , 53242@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) On 15/01/2022 16:02, Corwin Brust wrote: > I tried to follow this conversation but it wasn't clear to me what out > motive is for this change. The motive is that prior to change the alist with buffer-local variables was handled inconsistently. Sometimes with Fassoc, other times with Fassq and even assq_no_quit (the one that doesn't allow interrupts). Since the keys of alist are symbols (variable names), it doesn't make sense to use Fassoc which compares them with Fequal - an Fassq which does the comparison which simpler Feq would suffice. > I had understood we typically make (especially in the c sources) our > changes to achieve specific, tangible improvement.  Is that the case > here?  is the particularly oppressive 'tech debt'?  In the latter case, > does history reflect consideration wrt the original selections in each > of the various cases we hereby change? I don't know whether this is an oppressive tech debt, but from my perspective I have taken a look over handling of buffer-local variables during hacking some elisp code and saw the inconsistency. My patch is just an effort to reduce it and try to make Emacs a little bit better than it was before. I don't know what the improvement will be, probably in will be pretty small. My main consideration for selecting which function to use it to look at the types, notice that this in an associative list with symbols as keys and select the most appropriate function that would handle lookups in the list. > Also (and especially if we must 'clean for the sake of cleanliness'), > could we prefer the (seeming more conservative of UX) interruptable > varient in this case?  (Is that very costly? How costly and how have we > measured that?) Some parts before the change were already using uninterruptible variant. The Fassq does more work than assq_no_quit because it's not only interruptible but also checks for circular lists whereas assq_no_quit does not handle them correctly and would just loop forever. It is safe to use assq_no_quit for buffer-local variables because this in Emacs internal structure not visible to the user, Emacs fully maintains it and does not make it into a circular list. > Please consider the case of a package developer who may be abusing buffer-local vars during experiments. It seems this will cause much more ’oops, time to kill Emacs/grab a coffee'. I think it's unrealistic to introduce, even accidentally, enough buffer-local variables that lack of interruptibility in these particular functions will start to show. This is based on the following benchmark, which I encourage everyone to try out. It creates a list of length n and does one lookup into it. This corresponds to a buffer having n local variables and the lookup is the operation we're arguing about (Fassq vs assq_no_quit). The assq_no_quit is not exposed in elisp as it's not safe so the benchmark uses Fassq but assq_no_quit will be pretty close as it does roughly the same amount of work. (defun mk-list (n) (let ((res nil)) (dotimes (i n) (push (cons i nil) res)) res)) (byte-compile #'mk-list) (let* ((n 100000) (xs (mk-list n))) (benchmark-call (lambda () (assq 'foo xs)) 1)) It takes pretty large n to get the lookup take significant amount of time (please note that list creation time is not included in the calculation as it has nothing to do with Fassq vs assq_no_quit, so look at what benchmark-call returns and not on how long it all subjectively takes). On my machine I need 10 000 000 elements for lookup to take 110 ms, which is a noticeable amount of time (probably still bearable to work with). For Emacs to "freeze" over, say 10 second, the number of variables introduced has to be even higher. Is having millions (or hundreds of millions...) of buffer-local variables a reasonable scenario to consider? Please keep in mind that even if this occurs, interruptibility will not make lookups finish faster (even probably slower because of additional work that Fassq does compared to assq_no_quit). Yes, user would be able to C-g out of an operation if we use Fassq. But the operation will still be as much slow the next time it's performed. User will do the 'oops, time to kill Emacs/grab a coffee' sequence anyway in this case since any commands looking at local variables will be affected. AND this is the case with Emacs prior to my patch. Please do a benchmark and define 100 000 000 local variables and see whether Emacs works appropriately well in this case. I argue that if we're really concerned what would happen when someone defines a few hundred million local variables then we should not be asking a question whether reads of said variables are interruptible but should be asking a question whether linked list is the appropriate data structure to store local variables in the first place (spoiler alert: it's not). From unknown Tue Jun 17 01:46:44 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 13 Feb 2022 12:24:07 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator