(defun my-ag/font-lock-extend-region ()
    (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?

  • 2
    These variables are defvared in font-lock.el, so it is safe for you to do so too.
    – sds
    Mar 29, 2017 at 21:56
  • 1
    "(defvar ...)[...] may hide bugs" - what kind of bugs are you thinking of?
    – npostavs
    Mar 29, 2017 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, 2017 at 0:46

1 Answer 1


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.

  • Thanks for pointing to lexical vs dynamic binding. Now I see that dynamically bounded variables should be defvar.
    – gavenkoa
    Mar 30, 2017 at 6:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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