bug#62065: 30.0.50; No prompt to confirm unsafe local variables when eglot-ensure used in major mode hook

["João Távora" <joaotavora@gmail.com>]

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.