From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Declaring 'lexical-binding: nil' obsolete Date: Sat, 25 Sep 2021 17:50:52 -0700 Message-ID: References: <87r1dcw8hp.fsf@yahoo.com> <87h7e8w5vm.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21479"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , Emacs developers To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 26 02:51:41 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 1mUIOL-0005Qp-PZ for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Sep 2021 02:51:41 +0200 Original-Received: from localhost ([::1]:51388 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mUIOJ-00063K-Oh for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Sep 2021 20:51:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60806) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUINd-0005LN-Mc for emacs-devel@gnu.org; Sat, 25 Sep 2021 20:50:57 -0400 Original-Received: from mail-pl1-f177.google.com ([209.85.214.177]:35795) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mUINb-0008Ln-4t for emacs-devel@gnu.org; Sat, 25 Sep 2021 20:50:56 -0400 Original-Received: by mail-pl1-f177.google.com with SMTP id bb10so9191756plb.2 for ; Sat, 25 Sep 2021 17:50:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=5EAOX07eWOqaFkbYTvqNKp5WGMCUXfaFi5KrWBSEJcg=; b=a4whODLwB/BBcKT4fAxszsRYWg3iMtMMCQQ1YFvwhIicvUslGN+3f9gBbSR8+Xoa57 wJp3GfFuu/GEZqTYJo+W3MZZV9WG4uNyRQ+tHtWwkNg2AnUTTK5cK2+jKXoaWh6sa2FR 1GVnX5Pww31WSHAPd/7OIANdwJceUDvFNMFFByh7sMnD0RsUvhLPB63dLvVXwp1ryicZ ZCiopJ8zdB+hsgVxOJCo5xIhLUkE3UzP21XeZU4FTmW+7xniJR9v4l+G7VofuhCiDZ9K yH4sd2WzoDj1RhkdGnyP9Jzl9cH9AplaEemitGMy/sjWNX/3jAmTzFZxst9sTyML2Wfz c6KA== X-Gm-Message-State: AOAM532UxwhRkkjJTGA+X6aSXL4tlIaAxVKPNrU53Mq3ApFetVTyGln0 gxweteOFKZMkjBUSWd/20IUhmEqb9HezaHB021A= X-Google-Smtp-Source: ABdhPJzJM/6cM/VlASJ4mtG71TWMj69XVHuTpV/ga1emT3w1aLPhzPKYTlPqUzLvZ1E/c7ixzSHKo8nJhxbxYQ2jBDs= X-Received: by 2002:a17:902:d505:b0:13e:b49:9d8d with SMTP id b5-20020a170902d50500b0013e0b499d8dmr3952416plg.22.1632617452750; Sat, 25 Sep 2021 17:50:52 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 25 Sep 2021 17:50:52 -0700 In-Reply-To: <87h7e8w5vm.fsf@yahoo.com> Received-SPF: pass client-ip=209.85.214.177; envelope-from=stefankangas@gmail.com; helo=mail-pl1-f177.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:275494 Archived-At: Po Lu writes: > Stefan Kangas writes: > >> The roadmap I propose will give you a decade or so to adjust, and even >> then will you only need to change one line per ELisp file for it to work >> just as it does today. >> >> Before then, the worst that will happen is that you will see a warning. > > Yes, but is there any compelling reason other than "it's obsolete" to > make this change? Is there any compelling reason not to? Of course we have plenty of compelling reasons, but the main one is that we currently have two dialects of Emacs Lisp, where it would be better and less confusing to have one. > If it's to prevent new Emacs Lisp authors from inadvertently writing > dynamically-bound code, I suggest to rewrite (eintr)Prevent confusion > and other places in the documentation aimed at new users that seem to > encourage them to write dynamically-bound code. I'm sure that a large > part of the dynamically bound code present today stems from users not > knowing better; instead of a blanket obsoletion, better and more > immediate solutions can be found, such as updating the Introduction to > Programming in Emacs Lisp to not refer users to dynamic binding. I'm sure that we will review those parts of the documentation in due time. But the "blanket" (not sure why you add this word) obsoletion is precisely about discouraging the use of the 'lexical-binding:nil' dialect of Emacs Lisp. If you read my proposal carefully, I hope it is clear that this obsoletion mostly just entails our strong recommendation. Support for 'lexical-binding:nil' will need to be there for the foreseeable future. I do not include removing this feature in the plan I propose, and this is not by accident. > Perhaps a notice in Emacs Lisp mode when creating new dynamically bound > files would also be prudent. (For instance: "This file is being > dynamically bound. If you don't intend for it to be this way, please > read (elisp)Lexical Binding") (Note that we already have a warning in the mode-line.)