From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#55156: [PATCH] eval.c: New functions `defvar-f` and `defconst-f` Date: Thu, 28 Apr 2022 09:26:50 -0400 Message-ID: References: <83sfpxbwkg.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3361"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 55156@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 28 15:27:11 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 1nk4Ao-0000eW-Nt for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Apr 2022 15:27:11 +0200 Original-Received: from localhost ([::1]:32948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nk4An-0007gb-BP for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Apr 2022 09:27:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43074) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nk4Ag-0007gA-Gg for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2022 09:27:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51884) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nk4Ag-0007fP-7t for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2022 09:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nk4Ag-0004lQ-2v for bug-gnu-emacs@gnu.org; Thu, 28 Apr 2022 09:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Apr 2022 13:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55156 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 55156-submit@debbugs.gnu.org id=B55156.165115242018300 (code B ref 55156); Thu, 28 Apr 2022 13:27:02 +0000 Original-Received: (at 55156) by debbugs.gnu.org; 28 Apr 2022 13:27:00 +0000 Original-Received: from localhost ([127.0.0.1]:45781 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4Ae-0004l6-6g for submit@debbugs.gnu.org; Thu, 28 Apr 2022 09:27:00 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk4Ac-0004ku-OL for 55156@debbugs.gnu.org; Thu, 28 Apr 2022 09:26:59 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5BE3E100164; Thu, 28 Apr 2022 09:26:53 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8854F10028F; Thu, 28 Apr 2022 09:26:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1651152411; bh=7Erii6YWuzMbmmkCekV+1TQyN4dPNtxA2kl0ybVN+Rk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=AbYvxazw4AKixqLS2dKBMx/Elmy71RczIi71CR0+quBBaMNnK6OBpVN3HAzhqTx9l 56G2CsZiU6vUGNd2vLpzCMb+nyKVCHsbnpj8YlcptevitQdudMcNKsjz0BR6V8vdri S6MMgrIDOvX/MnpmxfWN2KbsBolSdMLECuApc8kGR645/x8Bf977Jun0buaWuYPAo0 d0wlrYxMZm+HPCvuf2I70Sstdxj8pMoYrdpsiXW9AiWeA5Wk9qoVjA9IxQXTh3lNeL NNxavsYHtptWpV/nuQu+1WqvPvSd319AJmGgygPv5O5+5Ry+8xT28PkUST6oSG4itU 459oN2OnlK/8w== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 63CEF120483; Thu, 28 Apr 2022 09:26:51 -0400 (EDT) In-Reply-To: <83sfpxbwkg.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 28 Apr 2022 08:34:23 +0300") 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:230875 Archived-At: >> -If @var{symbol} is already lexically bound (e.g., if the @code{defvar} >> -form occurs in a @code{let} form with lexical binding enabled), then >> -@code{defvar} sets the dynamic value. The lexical binding remains in >> +If @var{symbol} is already let bound (e.g., if the @code{defvar} >> +form occurs in a @code{let} form), then @code{defvar} sets the dynamic >> +outer value. The let binding remains in > > What is "dynamic outer value"? We don't have such terminology > anywhere in the manual. Good point, I should try and use the same terminology used by `default-toplevel-value` (and maybe refer to this function), thanks. >> @@ -763,17 +763,14 @@ DEFUN ("defvar", Fdefvar, Sdefvar, 1, UNEVALLED, 0, >> so that it is always dynamically bound even if `lexical-binding' is t. >> >> If SYMBOL's value is void and the optional argument INITVALUE is >> -provided, INITVALUE is evaluated and the result used to set SYMBOL's >> -value. If SYMBOL is buffer-local, its default value is what is set; >> +provided, INITVALUE is used to set SYMBOL's value. >> +If SYMBOL is buffer-local, its default value is what is set; >> buffer-local values are not affected. If INITVALUE is missing, >> SYMBOL's value is not set. > > This loses information, AFAIU: the previous doc string said INITVALUE > was evaluated, the new one says nothing at all about evaluating it. > If it is evaluated in some cases, please mention that; if it isn't > evaluated at all, please say that. I hesitated here. I preferred to remove the promise of when it's evaluated (which we currently break in some cases) rather than make a different promise, incompatible with the previous one. But now that Lars made me see that we actually do hold the promise in most cases, I think the better course of action is to keep the promise and fix the cases where we break it. >> -If SYMBOL has a local binding, then this form affects the local >> -binding. This is usually not what you want. Thus, if you need to >> -load a file defining variables, with this form or with `defconst' or >> -`defcustom', you should always load that file _outside_ any bindings >> -for these variables. (`defconst' and `defcustom' behave similarly in >> -this respect.) >> +If SYMBOL is let-bound, then this form does not affect the local let >> +binding but the outer (toplevel) binding. >> +(`defcustom' behaves similarly in this respect.) > > Isn't _this_ change (if it indeed constitutes a change in behavior) > scary? It was scary, yes, but that change happened back in: commit a104f656c8217b027866d32e8d7bf024a671e3cc Author: Stefan Monnier Date: Fri Aug 2 17:16:33 2013 -0400 Make defvar affect the default binding outside of any let. * src/eval.c (default_toplevel_binding): New function. (Fdefvar): Use it. (unbind_to, backtrace_eval_unrewind): Do a bit of CSE simplification. (Fdefault_toplevel_value, Fset_default_toplevel_value): New subrs. (syms_of_eval): Export them. * src/data.c (Fdefault_value): Micro cleanup. * src/term.c (init_tty): Use "false". * lisp/custom.el (custom-initialize-default, custom-initialize-set) (custom-initialize-reset, custom-initialize-changed): Affect the toplevel-default-value (bug#6275, bug#14586). * lisp/emacs-lisp/advice.el (ad-compile-function): Undo previous workaround for bug#6275. * test/automated/core-elisp-tests.el: New file. So this is just a long-overdue fix of its doc. >> +DEFUN ("defvar-f", Fdefvar_f, Sdefvar_f, 2, 3, 0, >> + doc: /* Like `defvar' but as a function. */) > > Please improve the doc string here. > >> +DEFUN ("defconst-f", Fdefconst_f, Sdefconst_f, 2, 3, 0, >> + doc: /* Like `defconst' but as a function. */) > > Likewise. How 'bout I use a double dash to make it more clear they're internal? Stefan