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@gmail.com> wrote:

> Matt Wittmann <mcwitt@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@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.
>
>