From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tom Gillespie Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] hack-one-local-variable use lexical-binding Date: Sat, 28 Nov 2020 23:12:14 -0500 Message-ID: References: <8E2B73D4-1269-4D0A-B572-7B6B47C46924@gnu.org> <83blfkqisb.fsf@gnu.org> 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="28287"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 29 05:13:19 2020 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 1kjE5O-0007IJ-QK for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Nov 2020 05:13:18 +0100 Original-Received: from localhost ([::1]:36046 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjE5N-0002zN-SH for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Nov 2020 23:13:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33578) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjE4d-0002WP-6X for emacs-devel@gnu.org; Sat, 28 Nov 2020 23:12:31 -0500 Original-Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]:38297) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kjE4a-0006Se-9F; Sat, 28 Nov 2020 23:12:30 -0500 Original-Received: by mail-wr1-x442.google.com with SMTP id p8so10390033wrx.5; Sat, 28 Nov 2020 20:12:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8+rONS0ZnqU0L3oYSkaEY/So3h90ZEaxFyrlv1uBYTg=; b=DCcxtR+KwGTXsPOQjkE2AVvw8kZctjUghbrY+suvcyjvxa6mo+tz+egy0mZ3+f3qHZ LJqeS9EGI3EMFGtTdtRyRjuL2Wy5WrAHjXinpMDsDKswkVOoeB2o84kO/eWkUCCDZCi3 UZsuiLyI7yohHWkMrtvgd5R+waZn7eoEIUOytAvm12WB9S12yueeBw02DLrwomjyQ9oO x5DK/psV2PTkzZ7MJxXDjkekhafrFmrckP2eKGs0dqG1a9bvwov0EOjtoDIg4IPuKc6o twUvXLi9XIkDlYDGbw3FWDBzYE9e3rpbWRb+yVPS5BEXnz65SpFf/bDHOlZC7MWsvYG8 ol7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8+rONS0ZnqU0L3oYSkaEY/So3h90ZEaxFyrlv1uBYTg=; b=JHhjsr6gtWYChHa/s7IK4NiJ1WqIMwO1MPecnz7FzDXStqeCprDI9TEh+IFf6CP4I2 AQ85TAPX2HZii318VxnODmt2FLxb1EgUQxD9PasibvC93Bwn2Db9Hm6v+Z66nojSaSH/ AYVHBMAjmvrtpQAsHJY45mfU5SgD7/Ye+H+nL0RmWltvaMlYvH2htuosdHO6yCTwlrnY l1j/KW2YnDnb0quEVQhZ4RZeQPlYN7EpuNemjjumbXluya7Bk8YEPhHCfJ7KmNVrQ+4r 2HGddrQznr/8QlncjYHzFM/9D4ACQnJBxu/jx4hlNo9n8kAKS6M+/75kSqI2joUa2WPn N2mw== X-Gm-Message-State: AOAM531L/xu720peAmh94w41HSzzCOH0AhmanHdLOzaX0DMI5BRYBtbT yIyOygznENrCfSLwZhHu0br/HkdDo6frGybHbYnWGx3b X-Google-Smtp-Source: ABdhPJyYkFGZbc96cPD9BXMbyZWaKAW9rODQCi3xN9yobDidDZvpWWmSTm79KeASFFyB9XLkFcLeFne9if3ilIvS3U4= X-Received: by 2002:adf:f783:: with SMTP id q3mr20289296wrp.88.1606623145608; Sat, 28 Nov 2020 20:12:25 -0800 (PST) In-Reply-To: <83blfkqisb.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::442; envelope-from=tgbugs@gmail.com; helo=mail-wr1-x442.google.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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:259986 Archived-At: > > > This would be a backward-incompatible change, wouldn't it? > > > > I've made exactly this kind of incompatible change many times over > > between Emacs-24 and now. I don't think we should worry about it. > > > > > I'd prefer a backward compatible solution. For example, how about > > > a separate lexical-eval clause, which will do this leaving eval to > > > work as it did before? > > > > As I said, that's over-engineering. > > We disagree. After reflecting on this I think that there is an important difference between the local variables list and the other special evaluation contexts which might make this not over-engineered. In the M-:, ielm, and scratch cases, there isn't an existing file, this is particularly relevant where it would be important to always have the same behavior in the minibuffer regardless of file. However, there is a file in the case of an eval local variable. For consistency this means that the file should have control over whether lexical or dynamic bindings is used. As noted in my original email, the current implementation would also allow users to control the lexical binding of the local variables independent of the rest of the file. While I personally have never encountered a case where someone explicitly sets lexical-binding: nil, I imagine that it would be surprising if elisp code in a file with that set was irreversibly forced into lexical mode despite the fact that the configuration option already must be present in the file. Obviously this would not be the case for non-elisp files, but since the prop line lexical-binding infrastructure is going to be around for the foreseeable future I'm not sure what there is to lose by simply passing lexical-binding instead of t. Best, Tom