From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: abq@bitrot.link Newsgroups: gmane.emacs.devel Subject: Re: Why is lexical-binding's global value ignored? Date: Tue, 31 Jan 2023 19:04:46 -0700 Message-ID: <190bb3292292a8e5932f97220c2a36c5@bitrot.link> References: <25094a24f891856fe0757fa34d80017b@bitrot.link> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30478"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 01 04:26:03 2023 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 1pN3l4-0007eo-Sz for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Feb 2023 04:26:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pN3k8-0002o7-JU; Tue, 31 Jan 2023 22:25:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pN2Ub-0008Of-69 for emacs-devel@gnu.org; Tue, 31 Jan 2023 21:04:57 -0500 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pN2UY-0001rh-6r for emacs-devel@gnu.org; Tue, 31 Jan 2023 21:04:56 -0500 Original-Received: (Authenticated sender: root@bitrot.link) by mail.gandi.net (Postfix) with ESMTPA id 5B417FF803 for ; Wed, 1 Feb 2023 02:04:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitrot.link; s=gm1; t=1675217087; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zgEb0q8SrJZiV6iacCMTvk2we5BCfpYc+rU+L8JbdVQ=; b=fbnn/D5MM2WIbdJw3NGL+FVMGK4JeMkh/P3RraBsseYa9qwlXnAWBBNVN9l99gFclTE/b6 WbCkzJ47kOxGT+UQOeu3jkV0mPNyco7sy4y+Ur0kXyGrZ0DWFozCHUB/WbphTZtC6S9/x2 qAGjF74jbeoJaqMXZvanY751JNNnOopyon5lwsTQgolm2gJzQz+ezXSJDNQ9sRDWR4e5re Wf07l8TmBHAQ/jFV2mBl4NVmTT9N1zYRh2hqrYz/moLkeiilX5tgMz2YFfMgyWpEUlMxQB JDT827M/oIQmdLzTWlvud5oC+FKMhhn4Ffl1o9tiP4dBGeqwlTOWTxlthREz+w== In-Reply-To: <25094a24f891856fe0757fa34d80017b@bitrot.link> X-Sender: abq@bitrot.link Received-SPF: pass client-ip=217.70.183.199; envelope-from=abq@bitrot.link; helo=relay9-d.mail.gandi.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 31 Jan 2023 22:25:02 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302844 Archived-At: Richard Stallman wrote: > A year or two after that. all packages people use will explicitly > specify lexical or not. At that point, we could safely change the > default, if we want to. Yes, and a great way to change the default would be specifically: First, start honoring the global value of the lexical-binding variable. At first, keep it nil by default, as it is now, so no behavior actually changes, and nothing breaks. But announce that the default will change in a future version. Of course, buffer local lexical-binding continues to work as it does now. Second, brave users can optionally setq-default lexical-binding t in the init file to get the new behavior now, and report breakage they discover in packages they use. Users who want the old behavior, or don't care about the issue and have no desire to learn about it, can ignore it, and nothing breaks. The default remains nil. Third, as announced long in advance, change the default to t in a future version, and announce that users can setq-default lexical-binding nil in the init file if they still want the old behavior. The key here is honoring the global value of lexical-binding. This makes the transition as smooth as possible, and makes it trivially easy for users to opt out even after the transition is complete and the default is t. The current problem is just that Emacs 24 through 28 ignores the global value. When loading a file, Emacs pretends that the global value is always nil even when it's actually t. (But of course, this entire discussion is irrelevant whenever lexical-binding is set buffer locally.) Honoring the global value is arguably just a bug fix. Or did you have another mechanism in mind for changing the default? Another possibility would be to still ignore the global value, but start pretending that it's always t even when it's actually nil. But surely nobody is advocating that Emacs ever do that. It makes much more sense to simply honor the global value (which could start right now, with no harm), then change the global default to t sometime in the future. There is a potential problem: Eli worries that “many people will not understand the disastrous consequences” of doing (setq-default lexical-binding t), and therefore he decided to delay honoring the global value. But a prominent warning DO NOT TOUCH THIS GLOBAL VARIABLE UNLESS YOU'RE AN EXPERT would be just as effective for Emacs 29 as it would be for Emacs 30 or even 42; the delay accomplishes nothing. And people who don't read the news at all, and just blindly upgrade and continue using their init file and packages unmodified, will experience no breakage, because the default remains nil. No adaptation is required, by anybody. There is another theoretical problem. Maybe somebody, somewhere, irrationally already does (setq-default lexical-binding t) in his init file, to no effect, and then (even more irrationally) subsequently relies on dynamic binding despite explicitly trying to set lexical binding. Any future version of Emacs that starts honoring the global value will break his config. But abstaining on his behalf is as unreasonable as total abstinence from ever adding any new global variable to any future version of Emacs ever again, due to the risk that the variable will conflict with somebody's private usage of it. Eli's decision is final, but it's worthwhile to make the situation clear.