From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sergey Vinokurov Newsgroups: gmane.emacs.bugs Subject: bug#53242: [PATCH] unify reads from local_var_alist Date: Sat, 15 Jan 2022 11:41:02 +0000 Message-ID: <15fa68fa-2bb2-eaf4-885b-abdff1e3f61f@gmail.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22716"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Cc: 53242@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 15 12:42:23 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 1n8hRu-0005n4-IL for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Jan 2022 12:42:22 +0100 Original-Received: from localhost ([::1]:36890 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n8hRs-0006an-Sk for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Jan 2022 06:42:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43552) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8hRa-0006Zh-BQ for bug-gnu-emacs@gnu.org; Sat, 15 Jan 2022 06:42:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46363) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n8hRa-0004cK-2I for bug-gnu-emacs@gnu.org; Sat, 15 Jan 2022 06:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n8hRZ-00062b-Uc for bug-gnu-emacs@gnu.org; Sat, 15 Jan 2022 06:42:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Sergey Vinokurov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 Jan 2022 11:42: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.164224687323156 (code B ref 53242); Sat, 15 Jan 2022 11:42:01 +0000 Original-Received: (at 53242) by debbugs.gnu.org; 15 Jan 2022 11:41:13 +0000 Original-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 Original-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 Original-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) Original-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) Content-Language: en-GB In-Reply-To: <83ee591mkr.fsf@gnu.org> 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:224291 Archived-At: 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.