all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Matt Wittmann <mcwitt@gmail.com>
To: "João Távora" <joaotavora@gmail.com>
Cc: 62065@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#62065: 30.0.50; No prompt to confirm unsafe local variables when eglot-ensure used in major mode hook
Date: Sun, 19 Mar 2023 18:07:24 -0700	[thread overview]
Message-ID: <CAJmFQmRZbrLktQWRqHrLXJBpH1FcoYVnSMj2taNZN4UBg2BsHg@mail.gmail.com> (raw)
In-Reply-To: <87ttyppxkt.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3736 bytes --]

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.
>
>

[-- Attachment #2: Type: text/html, Size: 4559 bytes --]

  reply	other threads:[~2023-03-20  1:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 20:59 bug#62065: 30.0.50; No prompt to confirm unsafe local variables when eglot-ensure used in major mode hook Matt Wittmann
2023-03-11  9:19 ` Eli Zaretskii
2023-03-11 11:13   ` João Távora
2023-03-11 15:01     ` João Távora
2023-03-11 16:23       ` Matt Wittmann
2023-03-12 19:40         ` João Távora
2023-03-20  1:07           ` Matt Wittmann [this message]
2023-03-20  1:21             ` João Távora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJmFQmRZbrLktQWRqHrLXJBpH1FcoYVnSMj2taNZN4UBg2BsHg@mail.gmail.com \
    --to=mcwitt@gmail.com \
    --cc=62065@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=joaotavora@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.