Re: position on changing defaults?

[storm@cua.dk (Kim F. Storm)]

David Kastrup <dak@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> 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?

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

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

Using the shift property doesn't imply using a pre-command-hook --
it can just as well be done at the command loop.

Also, checking for a shift property in the command loop (where we
lookup the key sequence) seems a lot simpler _and cleaner_ than
checking it inside call-interactively.

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?

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

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk