Re: Current mode command discovery

[Dmitry Gutov]

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.