Re: position on changing defaults?

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> David Kastrup <address@hidden> writes:
>
>> Stefan Monnier <address@hidden> writes:
>>
>>>>> AFAICT, the approach I proposed where most/all the movement commands get
>>>>> changed to call a special function in the interactive spec wouldn't
>>>>> suffer from any such problems.  I think it's the best approach so far.
>>>
>>>> I can not see what the advantage with an interactive spec over a property 
>>>> on
>>>> the function name is. Could you please tell?
>>>
>>> Very simple: no magic, no pre/post-command-hook.
>>
>> I think this functionality is eligible for an actual interactive spec
>> letter.  That makes people more comfortable with using it where
>> appropriate.
>
> I'm not sure about using a letter, but maybe a symbol like ^ at the
> head of the interactive spec is fairly clear.
>
> But will XEmacs ignore such an interactive spec symbol?

Why would that bother us?  We are talking about core editing macros: I
doubt that any of those will get copied verbatim into Emacs without also
synching the interactive-spec code.

> If not, it becomes harder to make external packages with movement
> commands which want to honor the "shift-region" feature of GNU Emacs.

By the time this interactive spec can be depended on to be available in
the Emacs variants one uses with those external packages, I suppose it
will have trickled into XEmacs as well.

So XEmacs is a bit of a red herring here.

> The 'shift property on the command name is transparent to those who
> don't understand it...

It is also ugly and does not lend itself to anonymous interactive
functions.  Would probably also not work well with function aliases.  It
is not my call to make, but I think the right place is the interactive
spec and not the rather arbitrary symbol that the function is bound to.

> Consider a case where some command (without the ^ spec) is bound to a
> shifted key, and it calls call-interactive on a movement command (with
> the ^ spec) -- then, should this activate the region or not?

Red herring: in either the case of an interactive spec or a property,
call-interactively would be the point to interpolate the shift key
here.  So this consideration is not relevant for the choice.

> If this is done in the command loop, such issues are clearly resolved.

What issues exactly?

-- 
David Kastrup