From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.bugs Subject: bug#53242: [PATCH] unify reads from local_var_alist Date: Sat, 15 Jan 2022 10:02:31 -0600 Message-ID: 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000018748205d5a10d59" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30905"; 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 Sat Jan 15 17:07:17 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 1n8laH-0007u7-H5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Jan 2022 17:07:17 +0100 Original-Received: from localhost ([::1]:38336 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n8laG-0002rT-5v for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Jan 2022 11:07:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58684) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8lWA-0001qk-OO for bug-gnu-emacs@gnu.org; Sat, 15 Jan 2022 11:03:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48672) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n8lWA-0003M0-FS for bug-gnu-emacs@gnu.org; Sat, 15 Jan 2022 11:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n8lWA-0005zC-Ao for bug-gnu-emacs@gnu.org; Sat, 15 Jan 2022 11:03:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Corwin Brust Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 Jan 2022 16:03:02 +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.164226257823001 (code B ref 53242); Sat, 15 Jan 2022 16:03:02 +0000 Original-Received: (at 53242) by debbugs.gnu.org; 15 Jan 2022 16:02:58 +0000 Original-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 Original-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 Original-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) In-Reply-To: <15fa68fa-2bb2-eaf4-885b-abdff1e3f61f@gmail.com> 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:224318 Archived-At: --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--