[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70217: [PATCH] Add substring-partial-completion style
From: |
Drew Adams |
Subject: |
bug#70217: [PATCH] Add substring-partial-completion style |
Date: |
Fri, 5 Apr 2024 19:46:07 +0000 |
> > It's preferable for this to be a separate style from partial-completion
> > rather than a customization for partial-completion, because completing
> > with a leading glob is inefficient: it doesn't allow the completion
> > table to do any filtering at all. So, for example, one might want the
> > regular partial-completion style to run first, and if it doesn't find
> > anything then the substring-partial-completion style can run.
>
> FWIW, I think the "language of completion styles"
> would benefit from being a bit richer.
FWIW, I agree. Richer in different ways/dimensions.
> I.e. instead of a completion style (i.e. an entry
> in `completion-styles`) being limited to a symbol,
> we could extend it so a style can take arguments.
>
> E.g. the `substring` style could take an argument
> which when set to the symbol `pcm` would cause it
> to behave like your "substring-partial-completion":
> (setq completion-styles '(basic (substring pcm) emacs22))
>
> Alternatively, it could be an argument to `partial-completion`, e.g.:
> (setq completion-styles '(basic (partial-completion notanchored) emacs22))
I'm not sure that's the best way/place to provide
for that, but yes, it's one possible direction for
enrichment.
___
FWIW, I think `completion-styles' is too rudimentary
in additional ways. (I've mentioned this before.)
1. There's only one set of completion styles that's
ever in effect. Each style is tried, in turn, until
one of them successfully completes your input.
They can only be used together - all or none; they
can never serve as alternatives that you can choose
interactively (runtime).
2. All completions you see come from the same style.
You have no control over which style will actually
be used for any given input, other than ordering
the styles ahead of time.
And you have no way of knowing which style was
actually used to produce a given set of candidates.
For users, the link (cognitive and otherwise) is
lost between a style and its completions for a
given input pattern.
The relation between your input pattern and the
matches is thus sometimes not so clear. There's
no way to know, e.g., that initial matching failed
and partial matching succeeded.
3. Instead of a single list of styles, Emacs should
support a set (list) of such lists, which you can
choose from at runtime. You can try completing
using one styles list and, if that doesn't succeed,
switch to another.
Since any such set can be a singleton, allowing
multiple sets also means you can use just a single
style.
4. Users should be able to define, for a specific
_command_, the possible styles sets to choose
from, and do so interactively.
___
I'd say Emacs should think about providing more
flexibility for what kinds of completing (and
sequences of such kinds, per `completing-styles')
are available and how users and code can move
among them or conditionalize them per context.
___
As an illustration, Icicles has long had such
possibilities (even before `completion-styles').
https://www.emacswiki.org/emacs/Icicles_-_Completion_Methods_and_Styles