"Lennart Borgman (gmail)" <address@hidden> writes:
David Kastrup wrote:
"Lennart Borgman (gmail)" <address@hidden> writes:
Richard Stallman wrote:
I think that `interactive' codes are much better than symbol properties
for defining the meaning of a command.
Yes, but the problem here is rather that you may need to redefine
which commands should deactivate the mark. Doing that with a symbol
property makes it much more flexible.
Read "flexible" as "conveniently hot-patchable around things not
designed for it". We have a policy not to use advice (another hotpatch
facility) for components distributed as part of Emacs because we want
all information pertaining to a particular function accessible and
readable from a single location in a clear manner.
I don't see this any different. If there is a need for a user to
hot-patch around functions not designed for it, advice is still
available.
But I believe this will only affect things on the command level. Is
not that a big difference?
The "command level" is distinguished by interactive forms. So there is
a difference in that we _already_ have a standard location where the
command level behavior is determined, namely the interactive form.
If people really want to hot-patch command behavior manually by poking
around with properties rather than advice, the 'interactive-form
property already provides enough leeway for that.
I don't see that we want to open the floodgates for all sort of bypasses
for command-specific properties attached to something other than the
interactive form.