Re: Shift selection using interactive spec

[David Kastrup]

Juri Linkov <address@hidden> writes:

>>>>> And the easiest way to do this is to change properties.
>>>>
>>>> I am not concerned about the easiest, but an appropriate way.
>>>
>>> Emacs should be easy to use and customize, not appropriate for some
>>> abstract goal.
>>
>> Giving a function a well-defined default behavior is not customization.
>> It is function definition.
>
> Shift-selection is not an inherent part of function definition since a
> function can normally work with or without this feature either way.

How is this different from any interactive call specification?  In
particular, from, say, the "*" flag in an interactive call string?

> And it would be very confusing to set a default behavior using
> interactive codes, but allow to modify it using properties.

So the solution is not to let properties meddle with this.  Fine with
me.

>>>> Properties are not part of either variable or function.  They are
>>>> part of the symbol.
>>>
>>> So what?  There are already about 200 distinct properties in Emacs
>>> attached indirectly to functions and variables via symbols, and they
>>> modify the default behavior, so the documentation should reveal them
>>> to users.
>>
>> But there is no _meaning_ conveyed by some property.  It is
>> undocumented.
>
> Of course, a property has a meaning, but it is different from the
> meaning of a command.

It has no _inherent_ meaning.  And there is no way of documenting any
meaning of it, anyway.

> For instance, `forward-char' has the meaning of moving point right n
> characters.  OTOH, the `shift-selection' property has the meaning of
> activating the mark before executing the command.

Before executing a command that happens to be bound to a particular
symbol, when this command is called in a particular way in the command
loop by doing symbol lookup.

That's very arbitrary.

> Those are different meanings of different features.

This is not even comparing apples and oranges.  It is comparing apples
and geography.

>>>> Lisp is Lisp, and Scheme is Scheme.
>>>
>>> And Emacs is Emacs (_extensible_, _customizable_, _self-documenting_
>>> real-time display editor).
>>
>> So what about "self-documenting" applies to arbitrary properties?  We
>> don't document functions by disassembling them, but by documentation
>> strings.  The presence of a property is not self-explanatory, and it is
>> not apparent whether it may affect the variable, the function, or
>> something else.
>
> Actually you presented the argument against using interactive codes
> for the shift-selection feature.  Using an interactive code will
> require adding a text like "This command activates the mark before its
> execution when Shift key is pressed" to the documentation string of
> the command.

Your point being?  Of course one adapts the function documentation
string as well when one changes the interactive code.  That's the same
with all other interactive calls.

But there is no way to change the DOC string when one tacks a property
onto the function.  And that means that the DOC string change and the
property tack-on are not inherently _synchronized_.  And that is a bad
idea.

> But when the user will turn off this feature (external to the function
> definition) the documentation string will lie to the user.

Make up a better documentation string, then, referring to the variable
which presumably turns on/off the feature.

> So it is clear that the shift-selection feature should not be part of
> function definition (not to have an interactive code nor corresponding
> text in its documentation string).

We can stop this right here.  There is _no_ _way_ whatsoever that you
will convince me that a part of the interactive behavior of the function
should _not_ be put into its interactive form and _not_ into its
documentation.

I consider this completely inappropriate.  You will not change my mind
on that.

> The only alternative to assigning properties to function symbols I see
> is creating a new user option with a list of command names that should
> activate the mark before their execution.

Again, this hides away part of the interactive behavior of a command to
a different place.  And again, it makes the mechanism depend on the
_name_ (aka symbol) of the called function rather than its function
definition.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum