From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.bugs Subject: bug#52063: 28.0.60; Confusing presentation of lambda Date: Wed, 24 Nov 2021 14:33:22 -0800 Message-ID: <9a8c985a-7042-a81c-5bf0-5117982c9cdc@gmail.com> References: <83czmqaegb.fsf@gnu.org> <874k82vwe5.fsf@gnus.org> <831r35afde.fsf@gnu.org> <87v90hu36b.fsf@gnus.org> <83v90h8zjw.fsf@gnu.org> <87r1b5u1cl.fsf@gnus.org> <83pmqp8vps.fsf@gnu.org> <87sfvly160.fsf@gnus.org> <83ilwh8pf2.fsf@gnu.org> <83a6ht8n3p.fsf@gnu.org> <83v90h72ki.fsf@gnu.org> <83r1b571mc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28183"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 52063@debbugs.gnu.org To: Eli Zaretskii , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 24 23:34:17 2021 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 1mq0qG-00077T-Qp for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Nov 2021 23:34:16 +0100 Original-Received: from localhost ([::1]:46824 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mq0qF-0004DP-Fi for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Nov 2021 17:34:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52420) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mq0q2-0004BK-Q6 for bug-gnu-emacs@gnu.org; Wed, 24 Nov 2021 17:34:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43602) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mq0q2-0005b1-HE for bug-gnu-emacs@gnu.org; Wed, 24 Nov 2021 17:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mq0q2-0007eu-Ba for bug-gnu-emacs@gnu.org; Wed, 24 Nov 2021 17:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Nov 2021 22:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52063 X-GNU-PR-Package: emacs Original-Received: via spool by 52063-submit@debbugs.gnu.org id=B52063.163779321729409 (code B ref 52063); Wed, 24 Nov 2021 22:34:02 +0000 Original-Received: (at 52063) by debbugs.gnu.org; 24 Nov 2021 22:33:37 +0000 Original-Received: from localhost ([127.0.0.1]:55148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mq0pa-0007eE-Dx for submit@debbugs.gnu.org; Wed, 24 Nov 2021 17:33:36 -0500 Original-Received: from mail-pl1-f173.google.com ([209.85.214.173]:45688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mq0pV-0007dv-DL for 52063@debbugs.gnu.org; Wed, 24 Nov 2021 17:33:33 -0500 Original-Received: by mail-pl1-f173.google.com with SMTP id b11so3013539pld.12 for <52063@debbugs.gnu.org>; Wed, 24 Nov 2021 14:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QUI/U3ETxDFE12pL+lpFqptGQDnrJ6D4ImuXXH2q62I=; b=fJxkzpyISr1G0Vj/TAmkuKIh2L9gOmXqlnmXGpwaISICOZmsOeVTYDq1Ej5CRVgPew VM6RNUTbK88JrBu3iSK0DyBahsXJBgvfQLUw8UgfB868lV5Yb2raHgd48x+mSIoYP37B sR8+ywQW115ma/VP82TdUuBbTkJpyBOqGs+QlTZQABoEntQvVUJmTBoftbeK7LsiblgB CqdQe6LBr+5i2ENZ7TZonGgK9ZMjmIdH+9aeUlT3zb2rn36BO8Yc3594Z+75Ldi/oucq T9i+hhQ2ir+zfI0lNlPf7j9IEZtCqDPigBXsrC+cjRERN3xTi+oxzwgCpkGaR1YIpm4k rPiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QUI/U3ETxDFE12pL+lpFqptGQDnrJ6D4ImuXXH2q62I=; b=kcRoFlW+XwYgT4eO6CT7uo3t2Ei70hLeLIszHGU22HSCWSe60IE61NBQ7FNaDUqxTm irUHo49a7hxo6RLXBB795rcx49IIp9leClSpUUoMl8wpgv7IaYyF/io7YZabWoUSn8HR O6Ehpei2+QQ5osEXBt4QRh5bj6c+FGLbmBTBEZ47D7a6dOauPiy+8zqNzyxudHc/K1GI 6cS15wj+1x3pxHOFKEfJ8TxBi44l1G2QpmPU8VVJ4cUpclU2J/jLAvQn7u3hsmSJbn29 +T63IgS8dS9jDa7xjDhfa3Ygi+Hkck6SP4jcKFXl8D7dd7ofFmu2MrrK9DBm6SQ0hbu5 AO4A== X-Gm-Message-State: AOAM532n3vhBgQ5RqvVXV/RnLJbwEPg6yqulrkaG0+6uTYRUvuHuz3Uq KVcL1ALdIJ+PMmI/yMHrm8hgThgjJpE= X-Google-Smtp-Source: ABdhPJzFgv6eHMP34fgtaoUfRy56MfMi6E0Ko2r2LjCVV9+GRLP2R5wz2hDNP4+OtRQYvyM9SADyUw== X-Received: by 2002:a17:903:2306:b0:141:e52e:457d with SMTP id d6-20020a170903230600b00141e52e457dmr23497559plh.3.1637793203242; Wed, 24 Nov 2021 14:33:23 -0800 (PST) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id h6sm775935pfh.82.2021.11.24.14.33.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Nov 2021 14:33:22 -0800 (PST) In-Reply-To: <83r1b571mc.fsf@gnu.org> Content-Language: en-US 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:220782 Archived-At: On 11/24/2021 12:14 PM, Eli Zaretskii wrote: > I look at the values to make sure they are what I expect. It's normal > in Emacs to do that, isn't it? I think in cases like that, it's useful to see the closure, since that's information that can help the user debug a problem. For example, if I have something like the following, it's helpful to see information about the closure: (let ((foo 1)) (add-hook 'prog-mode-hook (lambda () (setq foo 1)))) In that case, the value of prog-mode-hook is: ((closure ((foo . 1) t) nil (setq foo 1))) This is a contrived example, but similar sorts of things crop up in the real world. If the above example were significantly more complex (e.g. the `let' and the `add-hook' were in different functions), I might not realize that `foo' was lexically-bound unless I looked at the value of `prog-mode-hook' and saw the closure. As such, I think the current behavior is better than simply showing what the user typed, i.e. "(lambda () ...)". That doesn't show the variables bound by the closure. However, the specific representation of the closure object could use some improvement. For example, I don't know what purpose the `t' and `nil' serve, although I'm sure both are useful to experts in some situations. Is there a way to represent all this information in a way that's easy for users to understand without expecting them to know the details of how closures are implemented in Emacs?