From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.devel Subject: Re: Byte-compiler warnings for todo-mode.el Date: Mon, 06 Aug 2018 10:49:18 +0200 Message-ID: <8736vrop69.fsf@gmx.net> References: <87zhy0fs69.fsf@gmx.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1533545291 23950 195.159.176.226 (6 Aug 2018 08:48:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Aug 2018 08:48:11 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 06 10:48:07 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fmbBO-00066l-Dc for ged-emacs-devel@m.gmane.org; Mon, 06 Aug 2018 10:48:06 +0200 Original-Received: from localhost ([::1]:33069 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fmbDU-0001BB-RR for ged-emacs-devel@m.gmane.org; Mon, 06 Aug 2018 04:50:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54426) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fmbCq-0001Av-80 for emacs-devel@gnu.org; Mon, 06 Aug 2018 04:49:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fmbCl-00055j-7Y for emacs-devel@gnu.org; Mon, 06 Aug 2018 04:49:36 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:55409) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fmbCk-00055Q-TU for emacs-devel@gnu.org; Mon, 06 Aug 2018 04:49:31 -0400 Original-Received: from rosalinde ([178.1.61.114]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MfW5D-1fY6Di1PX1-00P4iy; Mon, 06 Aug 2018 10:49:21 +0200 In-Reply-To: (Stefan Monnier's message of "Sun, 05 Aug 2018 21:23:42 -0400") X-Provags-ID: V03:K1:mdLia98SfEr9DI0Iho1iOKwguT6CnmlrzJoVC/Gig2M07Cq1rik KhdZWVeEpPZ2POyrLv4W/5phzd+6xqDiawxzGRE4WXoXgUx62PjYHHSe2Pwh+9pRVwncepW Avz6pm3wQOh/Vm9CKWWaM7KZjbykgYFnfB8Wukz2T5P7yzm+A++7QqWhlS9wCZaqP9vBDUp YuNi6bO5m0p8O4w0YlYrw== X-UI-Out-Filterresults: notjunk:1;V01:K0:n5gxBDGgrwA=:GLMKyjP89UkXRCUv8ApCFu h81uHvb83cGdRr4KklxSB8/XDhh+ykh7zH72dtFrMLF9izKZDhk4q17UrC2TXPV4ssllO8Tmn h9Q3cyKBEyqXaZnW9WjH5xTysgCJGIL9JWq6EpYwEhln067CmVJwEogYZ+vdysdMECUPreNLy WxlkLoY0ays+/BZj2W9fqmVXfIv/3cHpSTdtGBAbLlcIC2F/r2G1x3WkFaTxiduvZzplDUY6c qcEKJEz77Km+1xXJ2B+vxVCsxvHDwbTxkXuvgnChSrdjj1pVD44M0ahlqkb68bxglaJYuAnRp JRoQUJszltc0BY3EYQSlh7TXDSnhpgmjxbbzEi4S2WLEFXb3G1Tx6KFNIvcHEYTyq1vgIRm+F OXZTjrXXgypwL0TiLwIhQKjkFL75HdEBBVLSktA6U9cS4jFuBvHBCZMUtkqbnS/f03pISkmQx m7D16WlTFcZ9aK5UuLJee+hHCKl+1FIITjBaBh7cV5lw6Z9O8weqgGoy9TuijmI5MlULR13Mf DNwXjlvg3gJ0g2hesEZg2ZaWXfXxSC0n/gD3KRer65n3myr0ZDxn+5AiYaOXRSURg9lhC3M9M byGul5JK1Lsm4wcKv5Yit4iriq2tdiou36Mu6XSnvmF4VXbdjl3AjpfLHd+aQXph0dlCYb/52 LkI8b06NP/4jnOlXfZg1nJ1YL6vHCXeBfzgpyhB62KWMEe/Utm8HMH7QxYU9+YXPvoUsMFVSG xJ2bT8fORRMErE8V1urQaE+cTep892PTUf7mf0VwV8a91sj61fufLXZlN2gA9TSralTAnns+ X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.18 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228209 Archived-At: On Sun, 05 Aug 2018 21:23:42 -0400 Stefan Monnier wrote: >> (let (... falist sfnlist ...) >> (dolist (f files) >> ... >> (push (...) falist)) >> (setq sfnlist (mapcar #'car falist)) >> (setq file (completing-read "Choose a filtered items file: " >> falist nil t nil 'sfnlist (caar falist))) >> ...) > > The above will not pass the value of `sfnlist` to `completing-read`. > I.e. the warning saying "Unused lexical variable =E2=80=98sfnlist=E2=80= =99" is true: > that variable is *not* used. Instead `completing-read` will look at the > symbol-value of the symbol `sfnlist` which is something completely > separate from the value of the lexical variable `sfnlist`. I thought I understood that this is so, but... >> Given this, is it acceptable to leave the warning or is it preferable to >> add a defvar to suppress it? > > Rename the var to `todo--sfnlist` and add a `defvar` for it, otherwise > the code will not do what you expect. ...starting emacs -Q with the above code and my ~/.emacs.d/todo/ directory, typing `F f' in todo-mode prompts for a filtered items file and repeating M-n brings up all and only the names of my filtered items files in the minibuffer, i.e., all and only the elements of sfnlist. Yet when I step through the code in Edebug, after evaluating the line (setq sfnlist (mapcar #'car falist)), the sexp (symbol-value 'sfnlist) indeed still evaluates to nil. So the code does appear to do exactly what I expect, although as you say it shouldn't. Can you explain this? In any case, I will add the defvar, since it is evidently canonical and correct. >> The second warning is due to this line: >> >> (if (and (boundp 'hl-line-mode) hl-line-mode) (hl-line-highlight)) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > (bound-and-true-p hl-line-mode) > >> The warning can be prevented with (eval-and-compile (require 'hl-line)). > > This ideally shouldn't remove the warning (i.e. if it does, as you say, > then it's probably the result of a bug or misfeature in the compiler). When I replace the above if-sexp with this: (when (and (eval-and-compile (require 'hl-line)) hl-line-mode) (hl-line-highlight)) and byte-compile the file in emacs -Q, Emacs does not produce the warning. Should I make a bug report? >> In fact, I use that elsewhere in todo-mode.el when hl-line-mode is >> actually enabled, so that when the function the above line of code is >> part of is executed, either hl-line.el is already loaded and >> hl-line-highlight is defined, or hl-line-mode is nil, so >> (hl-line-highlight) won't be evaluated and hence it doesn't matter if >> it's not defined. Given this, is it acceptable to leave the warning or >> is it preferable to suppress it? > > Your call. You can suppress the warning with > > (declare-function hl-line-highlight ...) > or > (if (and (boundp 'hl-line-mode) hl-line-mode (fboundp 'hl-line-highli= ght)) > (hl-line-highlight)) > > but the warning here is a false alarm, so if you don't mind seeing the > warning you can leave it (ideally, the byte-compiler should be made to > understand the connection between `hl-line-mode` and `hl-line-highlight` > so that your code doesn't trigger a warning). I'll leave the warning, then; maybe it will serve to inspire someone to teach the byte-compiler how to avoid it. Thanks for the feedback. Steve Berman