Re: Byte-compiler warnings for todo-mode.el

[Stephen Berman <stephen.berman@gmx.net>]

On Sun, 05 Aug 2018 21:23:42 -0400 Stefan Monnier <monnier@iro.umontreal.ca> 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