[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Byte-compiler warnings for todo-mode.el
From: |
Stephen Berman |
Subject: |
Re: Byte-compiler warnings for todo-mode.el |
Date: |
Mon, 06 Aug 2018 10:49:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
On Sun, 05 Aug 2018 21:23:42 -0400 Stefan Monnier <address@hidden> 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 ‘sfnlist’" 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-highlight))
> (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