|
From: | Dmitry Gutov |
Subject: | bug#22324: 25.0.50; completion-category-defaults style doesn't override completion-styles (gets prepended instead) |
Date: | Mon, 6 Dec 2021 04:16:52 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 |
On 02.12.2021 12:10, Lars Ingebrigtsen wrote:
--- This overrides the defaults specified in `completion-category-defaults'." --- And it does indeed prepend: (defun completion--category-override (category tag) (or (assq tag (cdr (assq category completion-category-overrides))) (assq tag (cdr (assq category completion-category-defaults))))) But... I think saying that that "overrides" is fine?
I think an "override" has a particular meaning, and that's replacing something that was there before. Not prepending to it.
Why is it important? Suppose the "category defaults" entry has a "permissive" style set up for a certain completion category.
As a user, I might try to override it with an entry in completion-category-overrides, to use a stricter style like 'partial-completion' or even 'basic'.
But what happens when my input fails to find any completions with the style I specified? It will fall back the default one, which is both surprising, given the current documentation, and can be problematic with respect to performance ('flex' is slower than 'partial-completion') and behavior (bringing lots of probably irrelevant completions which match my input because 'flex' is quite lax).
Whether one enjoys the lax behavior of 'flex', is more or less a user preference, and it seems one can't configure it entirely through completion-category-overrides. And since that variable is a defcustom and completion-category-defaults is not, it seems like we're limiting customization this way.
Though, of course, a user that's motivated enough can change the value of completion-category-defaults too.
[Prev in Thread] | Current Thread | [Next in Thread] |