bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[Augusto Stoffel]

Binding `completion-styles' buffer locally can lead to problems on
alternative completion UIs, say if the minibuffer is involved (this used
to happen with Consult's compeltion in region until recently).

It seems that a more appropriate way to override the completion style
would be to include a category in the completion table metadata, and add
a corresponding entry to `completion-category-defaults', which can be
done globally.

bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[João Távora]

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

On Tue, Apr 27, 2021 at 8:21 PM Augusto Stoffel <arstoffel@gmail.com> wrote:

> Binding `completion-styles' buffer locally can lead to problems on
> alternative completion UIs, say if the minibuffer is involved (this used
> to happen with Consult's compeltion in region until recently).
>
> It seems that a more appropriate way to override the completion style
> would be to include a category in the completion table metadata, and add
> a corresponding entry to `completion-category-defaults', which can be
> done globally.
>

Hi Augusto,

Yes, I think you are right about this.  And then Eglot's completion table
would use
use a category that points to the style? Is that the idea?  The end goal
is not to
lose flex-style completion for LSP-servers.

If so, can you draft a patch and attach it to your reply? By the way,
thanks for
inaugurating the Emacs bug tracker for Eglot bugs.

Also CCint Stefan Monnier since he usually has insight about this.

João

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

bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[Stefan Monnier]

>> Binding `completion-styles' buffer locally can lead to problems on
>> alternative completion UIs, say if the minibuffer is involved (this used
>> to happen with Consult's compeltion in region until recently).

Indeed; another reason it's problematic is that it's a user-config, so
changing it programatically will sooner or later interfere in
undesirable ways.

>> It seems that a more appropriate way to override the completion style
>> would be to include a category in the completion table metadata, and add
>> a corresponding entry to `completion-category-defaults', which can be
>> done globally.

That's right.  The advantage being also that the user can additionally
override that default style with `completion-category-overrides'.


        Stefan

bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[João Távora]

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

On Tue, Apr 27, 2021 at 9:38 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:
>
>
> >> It seems that a more appropriate way to override the completion style
> >> would be to include a category in the completion table metadata, and
add
> >> a corresponding entry to `completion-category-defaults', which can be
> >> done globally.
>
> That's right.  The advantage being also that the user can additionally
> override that default style with `completion-category-overrides'.
>
>
>         Stefan


Thanks. But can you confirm my hypothesis that it is possible to make
its completion table function in the `flex` style automatically, by

- having Eglot add an entry to completion-category-defaults or
  completion-category-overrides (which one?)

- having Eglot point to that entry in its completion table?

I.e. I'm only getting rid of the buffer-local hack if there's a viable
alternative (I think there is, but some confirmation would be ideal).

João

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

bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[Stefan Monnier]

>> >> It seems that a more appropriate way to override the completion style
>> >> would be to include a category in the completion table metadata, and
> add
>> >> a corresponding entry to `completion-category-defaults', which can be
>> >> done globally.
>>
>> That's right.  The advantage being also that the user can additionally
>> override that default style with `completion-category-overrides'.
>>
>>
>>         Stefan
>
>
> Thanks. But can you confirm my hypothesis that it is possible to make
> its completion table function in the `flex` style automatically,

Yes.

> - having Eglot add an entry to completion-category-defaults or
>   completion-category-overrides (which one?)

`completion-category-overrides` is a user config.  Don't touch it.

> - having Eglot point to that entry in its completion table?

There's no real notion of "point to", but it can use a completion-table
whose `category` says `eglot` and then use a corresponding entry in
`completion-category-defaults`, yes.

And those rare users who don't like `flex` (or who want the new
`mind-reader` completion style instead) can override it in their
`completion-category-overrides`.


        Stefan

bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[João Távora]

On Tue, Apr 27, 2021 at 11:37 PM Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> There's no real notion of "point to", but it can use a completion-table
> whose `category` says `eglot` and then use a corresponding entry in
> `completion-category-defaults`, yes.

Cool, that's exactly what I meant "point to".   And should
`completion-category-defaults` be affected globally, or buffer-locally?
(the table will only ever be useful in Eglot-managed buffers)

> And those rare users who don't like `flex` (or who want the new
> `mind-reader` completion style instead) can override it in their
> `completion-category-overrides`.

Great but you forgot the patch for the mind-reader completion style.

João (stealing Stefan's "forgot the patch" wisecrack)

bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[Stefan Monnier]

>> There's no real notion of "point to", but it can use a completion-table
>> whose `category` says `eglot` and then use a corresponding entry in
>> `completion-category-defaults`, yes.
>
> Cool, that's exactly what I meant "point to".   And should
> `completion-category-defaults` be affected globally, or buffer-locally?
> (the table will only ever be useful in Eglot-managed buffers)

I think you can just do it globally when loading Eglot (assuming you use
a category name that "belongs to Eglot").

>> And those rare users who don't like `flex` (or who want the new
>> `mind-reader` completion style instead) can override it in their
>> `completion-category-overrides`.
> Great but you forgot the patch for the mind-reader completion style.

I still have some bootstrapping problems with it, sorry.


        Stefan

bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[Augusto Stoffel]

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

Here is a patch setting `completion-category-defaults'.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-a-completion-category-defaults-entry.patch --]
[-- Type: text/x-patch, Size: 2179 bytes --]

From e9d877c9c7203ce999a935cdbc36c619255cf63c Mon Sep 17 00:00:00 2001
From: Augusto Stoffel <arstoffel@gmail.com>
Date: Wed, 28 Apr 2021 08:50:10 +0200
Subject: [PATCH] Add a completion-category-defaults entry

Setting `completion-styles' buffer locally is harder to customize and
can break some completion UIs

* eglot.el: Add a completion-category-defaults entry, if applicable.
* eglot.el (eglot--managed-mode): Don't set `completion-styles'
buffer-locally.
* eglot.el (eglot-completion-at-point): Add style metadata to
completion table.
---
 eglot.el | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/eglot.el b/eglot.el
index 3348054..122a76b 100644
--- a/eglot.el
+++ b/eglot.el
@@ -222,6 +222,10 @@ let the buffer grow forever."
   :type '(choice (const :tag "Don't show confirmation prompt" nil)
                  (symbol :tag "Show confirmation prompt" 'confirm)))
 
+;; Customizable via `completion-category-overrides'.
+(when (assoc 'flex completion-styles-alist)
+  (add-to-list 'completion-category-defaults '(eglot (styles flex basic))))
+
 \f
 ;;; Constants
 ;;;
@@ -1421,8 +1425,6 @@ Use `eglot-managed-p' to determine if current buffer is managed.")
     (eglot--setq-saving flymake-diagnostic-functions '(eglot-flymake-backend))
     (eglot--setq-saving company-backends '(company-capf))
     (eglot--setq-saving company-tooltip-align-annotations t)
-    (when (assoc 'flex completion-styles-alist)
-      (eglot--setq-saving completion-styles '(flex basic)))
     (unless (eglot--stay-out-of-p 'imenu)
       (add-function :before-until (local 'imenu-create-index-function)
                     #'eglot-imenu))
@@ -2166,7 +2168,8 @@ is not active."
                                    (get-text-property 0 'eglot--lsp-item c)
                                    :sortText)
                                   "")))))
-           (metadata `(metadata . ((display-sort-function . ,sort-completions))))
+           (metadata `(metadata (category . eglot)
+                                (display-sort-function . ,sort-completions)))
            resp items (cached-proxies :none)
            (proxies
             (lambda ()
-- 
2.30.2

bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[João Távora]

Augusto Stoffel <arstoffel@gmail.com> writes:

> Here is a patch setting `completion-category-defaults'.
>
> From e9d877c9c7203ce999a935cdbc36c619255cf63c Mon Sep 17 00:00:00 2001
> From: Augusto Stoffel <arstoffel@gmail.com>
> Date: Wed, 28 Apr 2021 08:50:10 +0200
> Subject: [PATCH] Add a completion-category-defaults entry

Thanks. Pushed to Eglot's upstream.  Closing this bug report.

João

bug#48073: [External] : bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[Drew Adams]

> Binding `completion-styles' buffer locally can lead to problems on
> alternative completion UIs, say if the minibuffer is involved (this
> used to happen with Consult's compeltion in region until recently).
> 
> It seems that a more appropriate way to override the completion style
> would be to include a category in the completion table metadata, and
> add a corresponding entry to `completion-category-defaults', which can be
> done globally.

1. I can't speak to what you say in your first paragraph,
other than to say that I'm not surprised that this can
cause problems.

I expect (but will be relieved if it's not the case)
that making global minibuffer variables buffer-local to
the minibuffer will break behavior in my "alternative
completion UI", which, I think, relies on not only code
but users interactively to be able to access, and even
change, the values of such variables (that is, without
having to wrap such access in `with-current-buffer' for
the current minibuffer buffer).

2. But I think I disagree with what you say in your 2nd
paragraph.  It should be possible for not only an
"alternative completion UI" to change `completion-style'
without recourse to modifying the completion table
(metadata or in any other way), but also for a user to
modify `completion-style' on the fly.

The completion table should, in general, define the
domain of possible completions, which are matchable
by user input.  In general, that domain can remain
constant even when `completion-style' is changed.
The domain defines what can be matched; the style
defines how domain elements can be matched.

It's true that a "completion table" can be a function
that, in effect, performs matching of user input as
well as defining the set of possible matches - together
in one operation.  But that's only one case.  (It's
general, because the function can also make use of a
non-varying domain.  But it need not do so.)

In my "alternative completion UI" users can, in general,
switch among `completion-styles' interactively, anytime
during completion.  If a `completion-style' gets, in
effect, baked into a given completion table for the
duration then that feature becomes impossible (I think,
but at least not easy) to make available.

Just one, non-expert, opinion.

bug#48073: [External] : bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[João Távora]

On Tue, Apr 27, 2021 at 10:28 PM Drew Adams <drew.adams@oracle.com> wrote:
> 1. I can't speak to what you say in your first paragraph,
> other than to say that I'm not surprised that this can
> cause problems.
>
> I expect (but will be relieved if it's not the case)
> that making global minibuffer variables buffer-local to
> the minibuffer will break behavior in my "alternative

Not to the minibuffer.  To the general buffer.  if your alternative
thing breaks like this, it will probably also break when the user
sets it legitimately.

In fact, I wonder if this is not also the case with the other UIs
that Augusto was having trouble with.

What I'm looking for is for a completion table-- a source
of completions -- to strongly suggest a completion style,
in case there's no explicit override by the user.

(Your other points kinda make sense, maybe, I didn't read
through all of them)

PS: Have you tried Eglot?  I wonder if Icicles works with it.  I admit
I've never tried Icicles myself, last time I tried was about 2006, but
i didn't even know how to load extensions very well.

Cheers,
João

bug#48073: [External] : bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[Drew Adams]

> > 1. I can't speak to what you say in your first paragraph,
> > other than to say that I'm not surprised that this can
> > cause problems.
> >
> > I expect (but will be relieved if it's not the case)
> > that making global minibuffer variables buffer-local to
> > the minibuffer will break behavior in my "alternative
> 
> Not to the minibuffer.  To the general buffer.  if your alternative
> thing breaks like this, it will probably also break when the user
> sets it legitimately.

Apologies for not following this thread more closely.
I thought this was about (connected to) the proposal
to make the global minibuffer variables, such as
`minibuffer-completion-table' buffer-local to the
minibuffer buffer.

> PS: Have you tried Eglot?  I wonder if Icicles works with it.  I admit
> I've never tried Icicles myself, last time I tried was about 2006, but
> i didn't even know how to load extensions very well.

No, I haven't tried Eglot.  And it's quite likely that
Icicles doesn't work with it.  I don't really have much
time for maintaining stuff, let alone time to experiment.
Sorry.

I don't claim that Icicles is at all typical wrt how it
uses the minibuffer completion table (or other things).
Not at all.  More and more things change in Emacs, so
that my code works less and less.  I used to find the
time and the will to try to keep afloat.  I no longer do.

bug#48073: [External] : bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[João Távora]

On Tue, Apr 27, 2021 at 11:06 PM Drew Adams <drew.adams@oracle.com> wrote:

> Apologies for not following this thread more closely.
> I thought this was about (connected to) the proposal
> to make the global minibuffer variables, such as
> `minibuffer-completion-table' buffer-local to the
> minibuffer buffer.

No prob!  Don't know anything about that other one.

> > PS: Have you tried Eglot?  I wonder if Icicles works with it.  I admit
> > I've never tried Icicles myself, last time I tried was about 2006, but
> > i didn't even know how to load extensions very well.
>
> No, I haven't tried Eglot.  And it's quite likely that
> Icicles doesn't work with it.

Why do you say that?  Does Icicles support the "normal"
completion tables that come with Emacs?

> I don't claim that Icicles is at all typical wrt how it
> uses the minibuffer completion table (or other things).
> Not at all.  More and more things change in Emacs, so
> that my code works less and less.  I used to find the
> time and the will to try to keep afloat.  I no longer do.

How gloomy and beautiful.  You should come to Portugal
to write odes of decadence to the Atlantic ocean.

João

bug#48073: [External] : bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[João Távora]

> How gloomy and beautiful.  You should come to Portugal
> to write odes of decadence to the Atlantic ocean.

...in suitably pompous French, of course.

bug#48073: [External] : bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[Drew Adams]

> > No, I haven't tried Eglot.  And it's quite likely that
> > Icicles doesn't work with it.
> 
> Why do you say that?  Does Icicles support the "normal"
> completion tables that come with Emacs?

Yes, it does.

> > I don't claim that Icicles is at all typical wrt how it
> > uses the minibuffer completion table (or other things).
> > Not at all.  More and more things change in Emacs, so
> > that my code works less and less.  I used to find the
> > time and the will to try to keep afloat.  I no longer do.
> 
> How gloomy and beautiful.  You should come to Portugal
> to write odes of decadence to the Atlantic ocean.
> ...in suitably pompous French, of course.

Sounds creative.

Speaking of gloomy (but not so beautiful): More and
more things are changing in the ocean too, alas. ;-)

bug#48073: [External] : bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?

[João Távora]

On Wed, Apr 28, 2021 at 5:10 PM Drew Adams <drew.adams@oracle.com> wrote:
>
> > > No, I haven't tried Eglot.  And it's quite likely that
> > > Icicles doesn't work with it.
> >
> > Why do you say that?  Does Icicles support the "normal"
> > completion tables that come with Emacs?
>
> Yes, it does.

Then, in theory, it should also work with Eglot.
I'll try to test someday, and bug you for help

> Speaking of gloomy (but not so beautiful): More and
> more things are changing in the ocean too, alas. ;-)

sad indeed. Then join a local environmental protection
group, maybe