1

For:

(defun my-ag/font-lock-extend-region ()
  (save-excursion
    (goto-char font-lock-beg)
    (forward-line 2)
    (setq font-lock-beg (point))))

I've got:

Warning: reference to free variable 'font-lock-beg'
Warning: assignment to free variable 'font-lock-beg'

Documentation says:

font-lock-extend-region-functions is a variable defined in ‘font-lock.el’.

Each function is called with no argument; it is expected to adjust the
dynamically bound variables ‘font-lock-beg’ and ‘font-lock-end’; and return
non-nil if it did make such an adjustment.

Usual solution (defvar ...) make this variables globally visible and may hide bugs.

How should I mask "reference/assignment to free variable" warning during compilation if variable is dynamically bounded?

|improve this question
  • 2
    These variables are defvared in font-lock.el, so it is safe for you to do so too. – sds Mar 29 '17 at 21:56
  • 1
    "(defvar ...)[...] may hide bugs" - what kind of bugs are you thinking of? – npostavs Mar 29 '17 at 22:48
  • 1
    As @sds said, these are global variables, declared as such in font-lock.el. If you load font-lock.el[c] before byte-compiling then you will see no such warning. Put (require 'font-lock) in your file that you're byte-compiling, and the warnings should go away. – Drew Mar 30 '17 at 0:46
2

Assuming you are using lexical binding, if the variable is dynamic, then it must be defvar'd (to ensure that lexical binding cannot treat it otherwise). AFAIK it would be a bug to not use defvar.

For a variable foo defined by some other library, you need only use:

(defvar foo)

to mark it as special/dynamic.

|improve this answer
  • Thanks for pointing to lexical vs dynamic binding. Now I see that dynamically bounded variables should be defvar. – gavenkoa Mar 30 '17 at 6:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.