From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 0/7] Cleanups and tests for DEFVAR_PER_BUFFER variables Date: Thu, 01 Apr 2021 19:39:56 -0400 Message-ID: <87y2e1wp4j.fsf@catern.com> References: <87a6qhyish.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="7418"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 02 01:40:57 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 1lS6vp-0001n2-2S for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Apr 2021 01:40:57 +0200 Original-Received: from localhost ([::1]:59102 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lS6vo-0003YG-3G for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 19:40:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37496) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lS6uw-00032r-L4 for emacs-devel@gnu.org; Thu, 01 Apr 2021 19:40:02 -0400 Original-Received: from venus.catern.com ([68.183.49.163]:37076) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lS6ut-00023s-G5; Thu, 01 Apr 2021 19:40:02 -0400 Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=98.7.229.235; helo=localhost; envelope-from=sbaugh@catern.com; receiver= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=catern.com; s=mail; t=1617320396; bh=XrNdC4/N7UqonP2bP8R2g3qU91qH8uEsYhHkHYx+Q8o=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=dFQ8EGe4qE53EqJHGbE+I2ENtDt/f0KVrmlZKJfBIyBXJYtDdgy3F8KWM3Qp0hMFA l82Ukz6+Xf/CATl+dlNvzu9XlLUigFnIgMbyvXIl7DoHXVBUVZRMRSm0jR5cCMGSwd AE7PxrMUXTylO6LF8/yTvadrCGlpLGzqWaTK9jhM= Original-Received: from localhost (cpe-98-7-229-235.nyc.res.rr.com [98.7.229.235]) by venus.catern.com (Postfix) with ESMTPSA id CA3942E6FAA; Thu, 1 Apr 2021 23:39:56 +0000 (UTC) In-Reply-To: Received-SPF: pass client-ip=68.183.49.163; envelope-from=sbaugh@catern.com; helo=venus.catern.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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:267285 Archived-At: Stefan Monnier writes: >> To statically avoid checking Qunbound for vars where it's not necessary, >> we need to use separate syntax for accessing BVARs that have defaults >> and BVARs that don't have defaults. Only BVARs that have defaults need a >> Qunbound check. (We could use the same syntax for both, but it would >> require X macros which Eli disliked earlier) > > 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). For sure, that has many benefits. I would have investigated this, but I don't know to what extent we try to provide backwards-compatibility for this kind of thing. If it doesn't break any of the tests, is it probably fine? Or if we're concerned about breaking third-party packages, how can one judge the risk of that? 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.