GNU bug report logs -
#62065
30.0.50; No prompt to confirm unsafe local variables when eglot-ensure used in major mode hook
Previous Next
Full log
Message #23 received at 62065 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Confirmed that the original issue seems to be resolved in master. I do see
the behavior you mentioned where I am asked to confirm a second time
immediately after the first unless I permanently mark the values as safe,
but otherwise it's working well for me. Thank you João!
Matt
On Sun, Mar 12, 2023 at 12:38 PM João Távora <joaotavora <at> gmail.com> wrote:
> Matt Wittmann <mcwitt <at> gmail.com> writes:
>
> >> Matt can you confirm this as well (both the error and the non-setting)?
> >
> > Confirmed both! (Sorry, I hadn't noticed the relevant message before.)
>
> I've pushed a fix to emacs-29. The commit message (which I repeat at
> the end of this email) explains the convoluted problem.
>
> There is a follow up problem. If the user answer "no" to the prompt
> which now correctly appears, that user will likely be prompted again
> immediately afterwards.
>
> That's because Eglot uses dir-locals, but only to get at the value of
> 'eglot-workspace-configuration'. This variable is usually automatically
> safe and won't motivate the prompt, but other unsafe variables are also
> "pulled in", and they motivate the prompt.
>
> I don't know how to fix this effectively without enhancing the
> dir-locals logic to allow for Eglot to ask to "pull in" just one
> variable, eglot-workspace-configuration.
>
> An attempt was made to bind noninteractive to true around Eglot's
> hack-dir-local-variables. That means that there is never the second
> prompt. Theoretically should allow eglot-workspace-configuration to
> come through if it is safe, even if other variables beside it are
> unsafe.
>
> Except that it doesn't. Could this be an alternative?
>
> So I'm at a loss here. The situation is better after the commit, but
> this safety-related confusion, where eglot-workspace-configuration
> somehow isn't set when neighbouring unsafe variables, can exist even
> eglot-ensure _isn't_ used.
>
> João
>
>
> ommit b916ec88b2ffe22a49128f17cdfb78f0ab1bc713
> Author: João Távora <joaotavora <at> gmail.com>
> Date: Sun Mar 12 18:19:40 2023 +0000
>
> Make eglot-ensure's post-command-hook run a bit later (bug#62065)
>
> 'eglot-ensure', typically used in the major-mode-hook, use
> 'post-command-hook' to schedule an automated, non-interactive
> connection attempt to a server. The goal is to connect when the
> buffer is ready, i.e. after the user command that found the file.
>
> However, if there are dir-local or buffer-local variables to confirm,
> finding the file will cause a minibuffer prompt to appear.
>
> In that case, 'eglot-ensure's addition to the global post-command-hook
> runs before it was intended too and a connection is started
> prematurely.
>
> In turn, this means that a call to 'hack-dir-local-variables' -- which
> is part of the connection process -- which also needs a minibuffer
> prompt, collides with the previous one. This generates an error and
> confuses the user, who doesn't know if the directory-local variables
> have been applied or not.
>
> This commit fixes the clash by having 'eglot-ensure' set
> 'post-command-hook' buffer-locally. This causes the automated
> connection to take place, as intended, after the user's original
> file-finding command has ended.
>
> However, the problem reported in bug#62065 is not completely fixed.
> If the user answers "no" to the first "confirm local variables"
> "prompt, she will be prompted again in the second one. A subsequent
> commit will address this separate problem.
>
> * lisp/progmodes/eglot.el (eglot-ensure): Use buffer-local
> post-command-hook.
>
>
[Message part 2 (text/html, inline)]
This bug report was last modified 2 years and 92 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.