RE: [External] : Re: Current mode command discovery

[Drew Adams]

> Talking about integration with other pre-existing functionality:
> how 'bout merging the new command enable functionality with the
> `menu-enable` symbol property?

Speaking of a symbol property...

IMHO, all of the shenanigans undertaken recently
to provide command enabling/filtering should be
replaced by simply using a property on command
symbols.  (Maybe more than one property, if you
really need something complex for some reason.)

That is, _IF_ this is to be done at all.

This is about association between a command and
certain contexts (modes, for example) in which
the command is considered relevant/enabled, or
not (or more or less so).

This isn't intended for anonymous commands, IIUC.
And for named commands the simple, flexible way
to handle such an association is using a property
on the command's symbol.

That gives libraries the ability to create or
modify such an association.  It gives commands
the ability to do it.  And it even gives users
the ability to do it.  Super flexible, simple -
can be done anywhere, in any context, at any time.
Can be done temporarily.

Why we would instead realize such an association
using an `interactive' form or a `declare' form,
I can't fathom.  That essentially hard-codes it
in source code.  Not so easy to modify, by any
party.

How did we get so far down this rabbit hole so
quickly?

I realize that this has already been suggested.
The threads are long and rambling, and I may well
have missed something, but I don't recall any
good reason given for rejecting this approach.