Re: Explain a bit more on how to configure language server in Eglot's manual

[Pedro Andres Aranda Gutierrez]

Hi,

>> But this exists: add-local add-dir-local-variable,
>> add-file-local-variable, customize-set-variable, set-variable are all
>> interactive functions that use the minibuffer.  But I don't think this
>> UI is the most suitable for this purpose.

>Then they should be upgraded so that they do become suitable, because
>this is first and foremost about editing variables.

There you could face resistance from people using the already existing
functionality.

>  For example, there could be:
> * a way to ask to do do the editing in a separate buffer
customize-set-variable

> * a way to insert the current value of the variable to be added
>   as the initial value of the thing to be read
.emacs.d/init.el or .dirlocals.el

> * a way to ask to use 'eval' of the user's input rather then just
>  'read' (here, an Eglot function could be used to spit out a plist
>  from a bunch of dotted strings in VSCode style).
> * maybe more?

I for me am not completely convinced that "VSCode-alike is good" ;-)

And to be 'positive', if the main issue here is VScode <-> emacs compatibility
what about a layer to read VSCode configs and converting them to Emacs LISP.
Because that's something that may be challenging.

/PA

On Mon, 6 Mar 2023 at 12:13, João Távora <joaotavora@gmail.com> wrote:
>
> On Mon, Mar 6, 2023 at 11:00 AM Augusto Stoffel <arstoffel@gmail.com> wrote:
> >
> > On Mon,  6 Mar 2023 at 10:51, João Távora wrote:
> >
> > > Conveniently editing Emacs variables (file-local, dir-local, buffer
> > > -local, global) interactively from the minibuffer (or some other similar
> > > place) is an idea that has been discussed before here.  We could
> > > restart that discussion.
> >
> > But this exists: add-local add-dir-local-variable,
> > add-file-local-variable, customize-set-variable, set-variable are all
> > interactive functions that use the minibuffer.  But I don't think this
> > UI is the most suitable for this purpose.
>
> Then they should be upgraded so that they do become suitable, because
> this is first and foremost about editing variables.  For example, there
> could be:
>
> * a way to ask to do do the editing in a separate buffer
> * a way to insert the current value of the variable to be added
>   as the initial value of the thing to be read
> * a way to ask to use 'eval' of the user's input rather then just
>   'read' (here, an Eglot function could be used to spit out a plist
>   from a bunch of dotted strings in VSCode style).
> * maybe more?
>
> Also, the LSP use case you're asking for here is for add-dir-local-variable
> where the directory is the current project's project-root.  So maybe a
> add-project-local-variable or somesuch would be a good first step.
>
> > > If such a mechanism  is eventually agreed on for Emacs in general, Eglot
> > > could very well take advantage, but don't think eglot.el should just make
> > > its own idiosyncratic take on that.
> >
> > AFAICT this mechanism has been agreed upon.  VC log, Magit commit, Org
> > capture, to name a few, all use the kind of UI I described.
>
> These are not for editing values of Emacs Lisp variables.
>
> João



-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet