From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Can't M-x compile-defun `edebug' because dynamic variables are falsely taken as lexical. Date: Thu, 13 Feb 2020 08:42:49 -0800 (PST) Message-ID: <29855ded-8607-4132-a80f-3204c06d74d9@default> References: <20170103141444.GA4649@acm.fritz.box> <20170103213228.GB2085@acm.fritz.box> <20170104133948.GA7373@acm.fritz.box> <20170104200458.GA2052@acm.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="401"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 13 17:43:40 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 1j2HaW-000Y29-Kp for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Feb 2020 17:43:40 +0100 Original-Received: from localhost ([::1]:55608 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2HaV-00061d-Kk for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Feb 2020 11:43:39 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55484) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j2HZq-0005bj-Qx for emacs-devel@gnu.org; Thu, 13 Feb 2020 11:42:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j2HZp-0003Lt-Ij for emacs-devel@gnu.org; Thu, 13 Feb 2020 11:42:58 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:57812) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j2HZp-0003Kd-AR for emacs-devel@gnu.org; Thu, 13 Feb 2020 11:42:57 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01DGVI7x130177; Thu, 13 Feb 2020 16:42:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=VPs7UvZ7gzV3cljHVUCW5vpZ3+MN0gcDP7ZEy2itaig=; b=gL+g1H6qkNp7ZXJD/4sjubFf/fj0Pa7tG/lwE5ZdQCpCS9hEEuvnrXPWIi27+xt7pFW4 Z1c1mmjexLGQ8za2cqgqkmQHECGKp7ie5tpbA8E+Wfsp6MChk9KWVJSBRGaSutKOBLVd EsluuU/lc8RqdSTW6XlMjMJYU6jTYOQkzdpJQVOrjvobl4+pghHdpA5GZxEO/W91tZkG 61S0WdFgHBqas2JIPUXzMPFTTMXz1UzxVZoeRNV0L4MSHhceXtSrDsEG9unmSpKr8rDu /QE8eTk0LJFGqryMKkKdk6m9nwg9yQ4VLTxf/2rU20MyR14W9udNcqHVyfCPW/swNckk yA== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2y2p3suj4y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Feb 2020 16:42:55 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01DGRKQX109446; Thu, 13 Feb 2020 16:42:55 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3020.oracle.com with ESMTP id 2y4k9jbjmb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Feb 2020 16:42:55 +0000 Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 01DGgoZM030240; Thu, 13 Feb 2020 16:42:50 GMT In-Reply-To: <20170104200458.GA2052@acm.fritz.box> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4954.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9530 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 spamscore=0 adultscore=0 bulkscore=0 phishscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002130122 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9530 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1015 impostorscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002130122 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.85 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:244919 Archived-At: Coming back to this old thread (2017). sm> > special-variable-p only indicates if sm> > (defvar VAR VAL . REST) was evaluated. And not (defvar VAR), apparently? am> So it would seem. There is a bug in the elisp manual, which says that = a am> variable being declared by defvar will cause special-variable-p to am> return t for it. The doc string looks right, though far from helpful am> for anybody who doesn't already know variable binding inside out, and am> even a bit cryptic for those who do. am>=20 am> special-variable-p would appear to be a near useless function, since it am> doesn't do what it's name says. am>=20 am> "Defining Variables" in the elisp manual states that "(defvar foo)" mak= es am> foo a special variable; yet "(special-variable-p 'foo)" returns nil. T= his am> has got to be a bug, of some sort. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ am> There appears to be no way of checking whether a variable's binding is am> (or will be) lexical. am>=20 am> I can foresee quite a bit of confusion happening over all this, if it am> hasn't happened already. am>=20 am> Am I missing something, or is this all really as incoherent as it am> appears to me? sm> It's useful for the compiler, but it's mostly internal, indeed. Reading the doc, a user will have no idea that this is "internal" mostly or not. And s?he will have no idea why (defvar foo) (special-variable-p 'foo) returns nil. Can we please fix the doc, to make things clear? If this function is really (or "mostly"?) internal=20 why document it in this way? Neither the manual nor the doc string gives a clue about this. Can we please get the doc to not mislead about this, at least in some way?