|
From: | Dmitry Gutov |
Subject: | Re: Current mode command discovery |
Date: | Sun, 14 Feb 2021 23:56:35 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 14.02.2021 22:49, Óscar Fuentes wrote:
AFAIU it fails for commands that are defined outside of the source file that `provide's the feature. This happens with large packages, which incidentally are the ones that define more commands. So the heuristics fails precisely where the filtering is most needed.
IME only a minority of packages are like that. Which possibly means that the majority of the commands are defined in packages which will satisfy the current logic of that implementation.
But those that don't, should be easy enough to augment by adding (mode -> (extra-package-1, extra-package-2, ...)) mapping somewhere.
This will still result in an order of magnitude fewer annotations than doing them for each command.
Any false negatives can be augmented with special (declare ...) instructions. But if we take that approach as a basis, fewer commands might such annotations.Yes, it would save many annotations, but not enough to use it as a basis (see above). Also, commands within a feature that are intended as generally applicable require an annotation too (to leave them out of the filtering.)
Yes, sure. This might actually require some special support inside 'declare', so that the command later could avoid scanning the whole obarray (if we care about that).
The approach has its merits, but it looks a bit too fragile to me.
I like it because the implementation without annotations should already work well enough for one to be able to get the feel of the feature (meaning, it will likely work better than the current new feature for quite some time, if one takes third-party packages without annotations into account).
And fixing the misbehaving cases can be done gradually, sort of like progressive improvement.
[Prev in Thread] | Current Thread | [Next in Thread] |