emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unsafe local variable in eglot.el


From: Tassilo Horn
Subject: Re: Unsafe local variable in eglot.el
Date: Fri, 10 Mar 2023 08:44:43 +0100
User-agent: mu4e 1.9.22; emacs 30.0.50

João Távora <joaotavora@gmail.com> writes:

>> Not sure what to do here.  Maybe adding an autoload-cookie to
>> eglot--debbugs-or-github-bug-uri does the trick?  Of course, then you
>> cannot find eglot.el without loading it at the same time...
>
> See my 01b65d442a commit to Emacs 29.  It's autoloading a "progn"
> block in eglot.el.  So visiting the file with bug-reference-mode does
> trigger a call to the helper function, which now exists.  But that
> call by itself won't cause eglot.el to to be loaded.  It's not very
> elegant, but it does solve the program effectively, I think (and the
> links work, of course).

Ah, and indeed that's the documented way according to (info "(elisp)
File Local Variables"):

--8<---------------cut here---------------start------------->8---
   When defining a user option using ‘defcustom’, you can set its
‘safe-local-variable’ property by adding the arguments ‘:safe FUNCTION’
to ‘defcustom’ (*note Variable Definitions::).  However, a safety
predicate defined using ‘:safe’ will only be known once the package that
contains the ‘defcustom’ is loaded, which is often too late.  As an
alternative, you can use the autoload cookie (*note Autoload::) to
assign the option its safety predicate, like this:

     ;;;###autoload (put 'VAR 'safe-local-variable 'PRED)

The safe value definitions specified with ‘autoload’ are copied into the
package’s autoloads file (‘loaddefs.el’ for most packages bundled with
Emacs), and are known to Emacs since the beginning of a session.
--8<---------------cut here---------------end--------------->8---

Great that it works now as intended.

Bye,
Tassilo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]