From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 0/7] Cleanups and tests for DEFVAR_PER_BUFFER variables Date: Thu, 01 Apr 2021 22:55:02 -0400 Message-ID: References: <87a6qhyish.fsf@catern.com> <87y2e1wp4j.fsf@catern.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23409"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 02 04:56:38 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lS9zB-0005yO-Tu for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Apr 2021 04:56:37 +0200 Original-Received: from localhost ([::1]:57816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lS9zA-0002qR-VZ for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 22:56:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lS9xt-0001zg-RY for emacs-devel@gnu.org; Thu, 01 Apr 2021 22:55:17 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:4609) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lS9xr-0002MU-9T; Thu, 01 Apr 2021 22:55:16 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8D047100205; Thu, 1 Apr 2021 22:55:13 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E33831000F4; Thu, 1 Apr 2021 22:55:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1617332111; bh=9MF2WQYpdCVC2jzZ7iTk5q6JZhNz5KXoRGSyeYZZZFQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=N/iGv1SHZzEtujwo+6iU2b2n1ST9tJsFR2runJeVtMsbi/P2TT4wb0RYJvKIJnzDh uMLE/7AP33Q3o7imcxMBUqf17WUWZNQ38uhQ5smHk2YEcqDIGrxcMqxLnn9J/lM+Jm d9xn5se2lVIWAISF8IXRrk7uUBwhPYf4YkNyPW+c4/JPC4BOpGsKHXsyLUGuLf9QWo mGOmGEXvAJ1GbBuj4ZPg+ogPTbOLjqeYANAwsqUzOeCCBVMeJMIIGUrjiFklRmv8rx VzYgkUblFWUGOu4MCjdjJpUK/gY4/7ArWgwEjs/s+mwNrRG5FwISQ1Sei+31LKGvu5 huUch+qlFajdA== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AB84F1201BE; Thu, 1 Apr 2021 22:55:11 -0400 (EDT) In-Reply-To: <87y2e1wp4j.fsf@catern.com> (Spencer Baugh's message of "Thu, 01 Apr 2021 19:39:56 -0400") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267287 Archived-At: >> BTW, we may also want to try and increase the proportion of those vars >> which don't have a global default (i.e. look at which variables fall >> into this camp and that can be changed without too much trouble). > I would have investigated this, I think we'd want to do things one step at a time, tho, so better concentrate on what you have now. > but I don't know to what extent we try to provide > backwards-compatibility for this kind of thing. We very much want to preserve backwards-compatibility. > If it doesn't break any of the tests, is it probably fine? No, that's definitely not sufficient. > Or if we're concerned about breaking third-party packages, how can one > judge the risk of that? Searching through uses of the variable in the packages we can find (GNU ELPA and MELPA are good starting points). It's hard work and often results in concluding that it's too risky. Tho often those problems can be seen much earlier, luckily. Better is to find some way to make the change gradually or to first install changes that detect when the code exploits the "to be old" behavior and emit messages warning about such a use. It's can be a long process. > If we could get rid of defaults from most of the variables, we could > just convert the rest into regular buffer-local variables and then > remove support for defaults in DEFVAR_PER_BUFFER entirely, which would > be a big simplification (and performance improvement). But of course > this depends on how many variables can have their defaults removed - > since converting a variable into a regular buffer-local variable will > make its performance worse for sure. Indeed, that's also my hope. I don't know how realistic it is, OTOH. Stefan