[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how to determine the current table (really) being used for minibuffe
Re: how to determine the current table (really) being used for minibuffer completion?
Sun, 27 Sep 2009 14:24:57 -0400
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)
> After successful completion, set a global variable to the symbol that
> represents the completion style.
Returning info via a global variable is evil.
> We already return the set of completions, and you've hacked that list
> to also carry the base size in its last cdr.
No, that was an ugly hack I managed to get rid of before releasing
> This third piece of info about the completion state can be returned in
> a global variable. (It can be at least as important as the base
> size, IMO.)
Reality check: you can't even come up with a concrete case where it
would be useful, so how can you claim it can be at least as important as
the base-size which has been needed since the introduction of
choose-completion (Emacs-21? Emacs-20?)
> Also, it is somewhat inconvenient to have `completion-styles-alist' as
> a defvar, not a defcustom. It is the real fulcrum for all of the
> code. It is baked once by Emacs development, and then it is used as
> the basis for the rest. User customization of `completion-styles' is
> limited to choosing among predefined styles.
A defcustom? It contains pointers to functions and those functions use
a non-trivial calling convention, so there's very little chance you'll
be able to add entries there without writing Lisp code.
`completion-styles-alist' is definitely not a candidate for defcustom.
> It would be better to have a single option that lets users both (a)
> choose the styles to use and (b) define new styles (their names and
> their defining completion functions). IOW, combine
> `completion-styles-alist' with `completion-styles' as a single option
> that users can customize.
And where do you keep the list of options from which they can choose?
> That way, the code would still automatically adjust to the possible set of
> completion styles, but those styles would not be limited to choices from a
> predefined list. Users could still just as easily add or remove predefined
> styles, but they could also more easily add their own.
How hard can it be to add their new style to completion-styles-alist and
then to completion-styles as well? Especially compared to the amount of
work required in writing that new style?
I must be misunderstanding something.
>> It might be easy in 99% of the cases, depending on exactly what
>> you want.
> See above.
The "above" didn't tell me what you want to do.
PS: FWIW, I can think of at least one case where the "file vs envvar"
information could potentially be used. So maybe if you try hard enough,
you too can come up with an example.