Re: Shift selection using interactive spec

[David Kastrup]

"Lennart Borgman (gmail)" <address@hidden> writes:

> David Kastrup wrote:
>> "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.
>
> Can you provide an example of how to change the interactive form for
> an existing function (without using advice of course)?

(put 'forward-char 'interactive-form '(interactive "*p"))

Seemingly has no effect (except on explicit interactive-form calls), but
that would seem more like a bug than a principal problem.

-- 
David Kastrup