From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ignacio Casso Newsgroups: gmane.emacs.bugs Subject: bug#54399: 27.2; Problems with (let ((custom-variable ...)) (autoload-function ...)) Date: Tue, 15 Mar 2022 12:50:05 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31944"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.10; emacs 27.2 To: 54399@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 15 16:53:22 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 1nU9UA-00084U-18 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 15 Mar 2022 16:53:22 +0100 Original-Received: from localhost ([::1]:47184 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nU9U8-0002Wf-PG for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 15 Mar 2022 11:53:20 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nU9Tq-0002WM-Vn for bug-gnu-emacs@gnu.org; Tue, 15 Mar 2022 11:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55491) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nU9Tq-0004qM-7b for bug-gnu-emacs@gnu.org; Tue, 15 Mar 2022 11:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nU9Tq-0002fK-6T for bug-gnu-emacs@gnu.org; Tue, 15 Mar 2022 11:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ignacio Casso Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Mar 2022 15:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 54399 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.164735952310160 (code B ref -1); Tue, 15 Mar 2022 15:53:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 15 Mar 2022 15:52:03 +0000 Original-Received: from localhost ([127.0.0.1]:49388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nU9Ss-0002do-PP for submit@debbugs.gnu.org; Tue, 15 Mar 2022 11:52:03 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:52860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nU9Sq-0002dO-Rm for submit@debbugs.gnu.org; Tue, 15 Mar 2022 11:52:01 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45682) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nU9Sq-0002TN-KS for bug-gnu-emacs@gnu.org; Tue, 15 Mar 2022 11:52:00 -0400 Original-Received: from mail-oln040092074058.outbound.protection.outlook.com ([40.92.74.58]:49778 helo=EUR04-DB3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nU9So-0004eu-5x for bug-gnu-emacs@gnu.org; Tue, 15 Mar 2022 11:51:59 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UhOsXjXpbISYev68UdVaahCFoRU2gqwlw3+n7fYG9VYyaHDsgXb1Qdcr1rO5lVFen0j1bMBmIPBreF8JiOQNN+odmoQsQuToqDMNenKghyg/ilhYX420duUl3c06BwK/IGRy0HfRFq/kO/YsLyYlrkkL9+IwcRzAIQb35Gb3l6owS0ob40df+p2XNAK7jQcggWwB5pr46dEu1A8iEKRzaddYUfmPIa9WJhk+H4hFL+XmGHb1NozuYLl2Gk21CST7txYyqdBn2HyLrnDRvdlYN2JA4ZiUUJAz+H3dAZvgQieovmtdyLUR/U3CrVpBDJBVOgBBn8vHqRBxpH8pAa8a2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5NoWvherqUwjiMr02BwJjtjhFtNoGNeSHoAlk/PEtaA=; b=U930Sfim/2bZ4H6ZP4QYRgQEwrJcEQ7lKck/zU0/BL9olyQLx40M/3XAHNrD+IcMDsm4eEuAW6UbQ1ZeaoD+0v0gKLmJEw+lA8A+ug2J20k7Nv/7ZgA0ioa6WT7lc3jLQDjJtEFUoNDytWmBpNJKuJ2sva14YUrAAdbuLat5MVzOADf99kq/EXwke52/NhcEs5jxYL6qXwQs7auDGbxiS3wB5vcR9EH/jekSx5fLjMkDLx2RS+4FLjicDwT07cST30QDuL10TMIDZ0lrsdNrThxcBsZrBp/Fq3SxlacFZVZ7lvh8vc3+zWuVGU5/DVv4fPKXgonJoY10ax+WmFUMYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5NoWvherqUwjiMr02BwJjtjhFtNoGNeSHoAlk/PEtaA=; b=btYDDuEwGUHJP8r7xZN0pYYG1zrA27FdiIoZaLzicoaqKpX5MknRPgsHPAqkT49Le6juuAyeIqyTgzBuN17GZzdw1mAocWmPKz63pAJEqVHlJkOD9FQtyhcDa7V2ohjtoSUgRzznjbnTBG7EBfoHsRiVc3bynQWwXOVuEnXClxKsPp5IK+N+apwGhwgvHB1RLsFPvPbiEZP9S2+HoZE9DkoOW7Bt8m68vvQDVjDjPJVJnXhRDESgH7jLTNrsHxVIJdZaht4vU/1xfkck20QdZGMjWfqCi2J78vHTm8mSV+h1bBGWghmf7ujtMIcpNBN+WUQYwdv1sGc3FauHvywmxg== Original-Received: from PAXPR06MB7760.eurprd06.prod.outlook.com (2603:10a6:102:155::8) by DB7PR06MB4759.eurprd06.prod.outlook.com (2603:10a6:10:59::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5061.26; Tue, 15 Mar 2022 15:31:26 +0000 Original-Received: from PAXPR06MB7760.eurprd06.prod.outlook.com ([fe80::e05a:8d81:8648:b10f]) by PAXPR06MB7760.eurprd06.prod.outlook.com ([fe80::e05a:8d81:8648:b10f%9]) with mapi id 15.20.5061.028; Tue, 15 Mar 2022 15:31:26 +0000 X-TMN: [pSJjsx+pwHxukMt51Af/RD4O+pDdYK4+] X-ClientProxiedBy: MR2P264CA0087.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:32::27) To PAXPR06MB7760.eurprd06.prod.outlook.com (2603:10a6:102:155::8) X-Microsoft-Original-Message-ID: <87mthr1bcj.fsf@hotmail.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7e0b6364-35d8-43c7-093f-08da0698de2c X-MS-TrafficTypeDiagnostic: DB7PR06MB4759:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LUmK45UBbhXl7IBrjfUKn+TeNAs3xM/hjPXLkQZP+Icc4f0p0QtnAXWkxtTYUh72s18F9wngDX6ad8pYEyD5d0d+3CikrF/xD1eHCX+qA3XAoXplNc4wHv/XuRMsWWRh+UsA2lg+HkHpZrT46NkeweGsG6QF7zjvO4FyJPSbhDPTzJZjtGTyNkYJpjrrKgm/pv//QGWTlVM1nwlDQP+IGNT1eiz5C0dWkmnfwFwNqcM3zaU6vY9NKuIogtpK/PWBLSYWwYSu18fzaTVvQyRQ5xEi11yX9spBhzWwzsdusO6XZ7zubK9+7KoLVuO9Ywn7UgHouS+TKRsDSaqEeDwt9WTxtia/WQJb+q84VyEF62frmHcmaEWgBwFNP6609H7B4WvEJ7DYCJtKGOj9jSgUMbz3XgikhXtHqzp2mOj3eJiOwUWl4N7QJJVTCeKmrHucpqVX/cMjZRyOKbfKWSBAy8rjAIFHWfyh6up0HtLI1sxaB1ARGJ5kolkkLwiT0HUkg34GRyhi2umD0k5cgDdo1TmHbdM7TLNReapqcRO560SPeDOiRpF5ODDZFpGVSYUZXUXZ3QhQGsTti15CDoiFYqfjMvYR9KgODxoMuyWgIKjYRiAIFUIOMr0XwrHCxm8I X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: CgJDNh4Qup+t0gzfn+orUSOpBSm9lF9h9cx+xaCfuhPk4S9jm89Vpr+IR498cNHrZ+PmHn8IWG4zYvmjGyRbaqjLc+DyQ1N9mPlSgnIzmPjJgLVIQsGtEAoWXcV+JfUhmr83ItvxWDSa/ZDguYu5BYB8NpSkdIyxUEyfrLm2FJfmksqbWDr53aoCofjaTKqkSj3RGp5UczDDqK9RhNQA2IRkoTbGBSBPlFNyywdA83qU06jOfjt0CHMmcejxP6eoFwz7sxApUd2b1GG+IAacuQd6e1PyHQEuglKpZPYn8op/clVeqk1pmy+bre/2ajA1aCdxuBVFlOrbXnxE4uSmC1uxzHvY4177crJheeMXwVoDq6l+YvjYZL4BIUlwGfiteOwaOt9WpdxmnGkcomOmn6aKBvmECqjE1DODjJgGSoNo6r1a+6aKpnfyhaDJnqm8n+xZq8IxodRZ6AmTcHfFgMB82B6lmoWcBWeszfHe6lHbU2a9tUqHAbkSgMgo0KrweptAN3E5E1U+r7GADWSEjBOQqHzIy1QzTaNCAEbT43sZ4lrRIyanJuNMRFrS3GIRv/AFmBQeOjS9X+dB/fqJ8JKzxXFYchC1JylAsu71Xpwe4PwOIf1O4uZxuuzveyOQLTf7EEzv6YOJll4VEJbOYujwvRl26M9V2a4W7p8cEl9AdaTJCKkqlsMvynp6wpiDi0PcyNOh7vd2OjsAoR6NC2A6rdn8d61QADMUIBSphvCU7bRmDrpVb4hz3d 38AWfVgHHKr+ndF3A6UPAQBNWLRf0sFlLhizr1XQSYSjeg/b9rzwlv1wzt54cZVoID30laWopj7wP7NX/Py/smTRqEaQqrv3g9 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-6e454.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 7e0b6364-35d8-43c7-093f-08da0698de2c X-MS-Exchange-CrossTenant-AuthSource: PAXPR06MB7760.eurprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2022 15:31:26.1225 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR06MB4759 Received-SPF: pass client-ip=40.92.74.58; envelope-from=ignaciocasso@hotmail.com; helo=EUR04-DB3-obe.outbound.protection.outlook.com X-Spam_score_int: -4 X-Spam_score: -0.5 X-Spam_bar: / X-Spam_report: (-0.5 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action 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:228409 Archived-At: Hello, I reported this org-mode bug in https://lists.gnu.org/archive/html/emacs-orgmode/2022-03/msg00085.html, but after some discussion we figured out that the issue is not particular to org-mode but generic to all Emacs and decided to bring our conclusions and questions here. The problem is the following: Calling an autoload function under the following circumstances does not always work as expected: - the function uses a variable defined with defcustom in the same file as the function. - the function is called inside a let form that binds that same variable. - the file defining the function and the variable has not been loaded yet at the time the function is called, and the variable has not been set either. I would expect to work exactly the same as if the file had already been loaded. Instead, the following happens depending on the scoping and the defcustom setter: 1) If the let form is evaluated with lexical-binding, and the variable is not also autoloaded, Emacs does not know the variable is special by the time it evaluates let, so it uses lexical binding. Later, when it evaluates defcustom and it finds out that it is special and it should have used dynamic binding, Emacs 29 produces the error (error "Defining as dynamic an already lexical var"). Emacs 27 does not perform this check and keeps going, and since it uses lexical binding, the let binding has not effect at all inside the function as the user would expect. The exact same thing happens also if the variable is defined with defvar. I guess there is nothing that can be done about it otherwise Emacs 29 would have done so instead of throwing an error. The following form reproduces this behavior (please ensure to evaluate it with lexical binding): (progn (defun my-load () (defvar my-var 1) (message "Value while loading: %s" my-var)) (defun my-var-alias () my-var) (let ((my-var 2)) (my-load) (message "Lexical value inside let: %s" my-var) (message "Dynamic value inside let: %s" (my-var-alias))) (message "Value ouside let: %s" my-var)) 2) If the let form is evaluated with dynamic binding, or the variable has also an autoload cookie so Emacs already knows is dynamic, then the behavior depends on the :set argument of defcustom: 2.1) If no explicit argument is passed, then defcustom uses as default set-default-toplevel-value. In that case everything works as expected. Note however that the documentation and comments says in many places that the default :set argument is just set-default instead of set-default-toplevel-value. 2.2) If the :set argument is set or set-default (the suggested default choice in the documentation), that function is called with arguments the variable symbol and the standard value passed as argument to defcustom. But those functions only affect the scope of the let binding, which means that a) they overwrite the let binding, which is not what the user expect, and b) when the evaluation of the let form finish the variable is void. Thus, any further use of that variable or functions that use it will produce a void variable error. And this is not trivial to fix: requiring the feature again will do nothing since it's already provided, so the user needs to finds it's definition and evaluate defvar/defcustom again himself, or restart Emacs. The following form reproduces this behavior (please ensure to evaluate it with dynamic binding): (progn (defun my-load () (defcustom my-other-var 1 "Test variable" :set 'set-default) (message "Value while loading: %s" my-other-var)) (let ((my-other-var 2)) (my-load) (message "Value inside let: %s" (my-other-var-alias))) (message "Value ouside let: %s" my-other-var)) I think that something should be done about point 2.2. Some suggestions are: - A warning when defcustom of a variable is called inside a let binding of that same variable. - Update documentation of defcustom to say that the default choice of the :set argument is set-default-toplevel-value - Document default-value, default-boundp, and set-default to say that they may not work as the user expects when called inside a let binding with dynamic binding enabled. The snippets below show how I expected them to work (please evaluate them with dynamic binding): (let ((fresh-var 1)) (default-value 'fresh-var)) ;; I expect and error, it returns 1 (let ((another-fresh-var 1)) (default-boundp 'another-fresh-var)) ;; I expect nil, it returns t (defvar yet-another-fresh-var 1) (let ((yet-another-fresh-var 2)) (set-default 'yet-another-fresh-var 3) yet-another-fresh-var) ;; I expect 2, it returns 3 yet-another-fresh-var ;; I expect 3, it returns 1 What do you think?