bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#48073: [External] : bug#48073: 27.2; [Eglot] Don't bind `completion-styles' buffer locally?
Date: Tue, 27 Apr 2021 21:01:01 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]