Re: Interactive hat.

Re: Interactive hat.

[naesten]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Thu, Mar 26, 2009 at 5:18 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> As explained in my message of a couple days ago, it should always
> be easy to turn an interactive string into the corresponding lisp form.

Perhaps there should be a function (and command?) to do just that? It might help people to remember not to add anything to the string without providing a corresponding lisp function/macro. (Not that that is likely to happen very often or anything...)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

bug#2760: CUA-like stuff spuriously enables transient-mark-mode.

[Alan Mackenzie]

Hi, Richard, Eli and Emacs!

Start the CVS head "emacs -Q", and evaluate this:

    (global-set-key [ &\C-\M-\S-m ] 'forward-char)
    (transient-mark-mode -1)

In some buffer, invoke 'forward-char by the above binding.  This enables
transient-mark-mode as a side effect.  This shouldn't happen.  It happens
both in a Linux Virtual terminal (with the requisite enhancements to the
keyboard handling) and in X-Windows.

ANALYSIS:
---------
The "^" in the interactive string causes `handle-shift-selection' to be
invoked by the command loop.  The function and friends abuse the user
option variable `transient-mark-mode' by additionally storing some sort
of state in it.  h-s-s writes the value '(only) into the variable
transient-mark-mode, thus enabling the mode.  A sensible fix would surely
involve leaving `transient-mark-mode' severely alone (only the user
should set this) and creating another variable (or several) to hold the
state currently mashed into t-m-m.

COMMENT:
--------
It is now no longer true that "But Emacs does not assign meanings to keys
directly" (Emacs manual, page "Commands") - Emacs directly assigns a
meaning to the shift key.  This is surely a Bad Thing.

Why, why, why is this thing implemented by hard-coding in the command
loop, where it interferes with users' ability to chose key bindings?
Surely this feature with the shift key should have been implemented by
defining defuns such as `forward-char-with-marking', and putting these
commands in some suitable keymap?  OK, it's more work, but not _that_
much more.

It's practically 100% certain that somebody, somewhere, will want to use
the hyper- or alt- keys instead of <shift> to get this visible region
feature, or possibly might want to use separate bindings entirely.

It's near 100% certain that somebody, somewhere, perhaps with a name like
Xah Lee, will want to use C-f as "find" (i.e. bind it to
`isearch-forward') and use C-S-f for `forward-char'.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#2760: CUA-like stuff spuriously enables transient-mark-mode.

[Stefan Monnier]

> Start the CVS head "emacs -Q", and evaluate this:

>     (global-set-key [ &\C-\M-\S-m ] 'forward-char)
>     (transient-mark-mode -1)

> In some buffer, invoke 'forward-char by the above binding.  This enables
> transient-mark-mode as a side effect.  This shouldn't happen.

Can't reproduce it here (I tried the above, after replacing & with ?
and I don't see any indication that transient-mark-mode is being set).

> Why, why, why is this thing implemented by hard-coding in the command
> loop, where it interferes with users' ability to chose key bindings?

Where do you see it hardcoded in the command loop?

> It's practically 100% certain that somebody, somewhere, will want to use
> the hyper- or alt- keys instead of <shift> to get this visible region

We'll cross this bridge when we get there.

> It's near 100% certain that somebody, somewhere, perhaps with a name like
> Xah Lee, will want to use C-f as "find" (i.e. bind it to
> `isearch-forward') and use C-S-f for `forward-char'.

And that works just fine, AFAICT.


        Stefan

bug#2760: CUA-like stuff spuriously enables transient-mark-mode.

[Alan Mackenzie]

Hi, Stefan!

On Mon, Mar 23, 2009 at 08:46:22PM -0400, Stefan Monnier wrote:
> > Start the CVS head "emacs -Q", and evaluate this:

> >     (global-set-key [ &\C-\M-\S-m ] 'forward-char)
> >     (transient-mark-mode -1)

> > In some buffer, invoke 'forward-char by the above binding.  This enables
> > transient-mark-mode as a side effect.  This shouldn't happen.

> Can't reproduce it here (I tried the above, after replacing & with ?
> and I don't see any indication that transient-mark-mode is being set).

Sorry, my mistake.  Yes I did mean "?" in the binding, but as depicted
above, the bug doesn't happen.

Instead,

    (global-set-key [ ?\C-\M-m ] 'forward-char)

Now invoke forward-char with this binding + the shift key.  This enables
transient-mark-mode as a side effect.  This shouldn't happen.^H^H^H^H....

Correction: this can be disabled by nullifying the option
shift-select-mode - which isn't yet documented in the Emacs manual.  So I
withdraw my complaint, with apologies.

> > Why, why, why is this thing implemented by hard-coding in the command
> > loop, where it interferes with users' ability to chose key bindings?

> Where do you see it hardcoded in the command loop?

In Fcall_interactively, Lines 207 and 231, where it is interpreting the
interactive string:

      else if (*string == '^')
        {
          if (! NILP (Vshift_select_mode))
             call1 (Qhandle_shift_selection, Qnil);    <================
          /* Even if shift-select-mode is off, temporarily active
             regions could be set using the mouse, and should be
             deactivated.  */
          else if (CONSP (Vtransient_mark_mode)
                   && EQ (XCAR (Vtransient_mark_mode), Qonly))
            call1 (Qhandle_shift_selection, Qt);       <================
          string++;
        }
.

> > It's practically 100% certain that somebody, somewhere, will want to use
> > the hyper- or alt- keys instead of <shift> to get this visible region

> We'll cross this bridge when we get there.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#2760: CUA-like stuff spuriously enables transient-mark-mode.

[Stefan Monnier]

>> Where do you see it hardcoded in the command loop?

> In Fcall_interactively, Lines 207 and 231, where it is interpreting the
> interactive string:

>       else if (*string == '^')
>         {
>           if (! NILP (Vshift_select_mode))
>              call1 (Qhandle_shift_selection, Qnil);    <================
>           /* Even if shift-select-mode is off, temporarily active
>              regions could be set using the mouse, and should be
>              deactivated.  */
>           else if (CONSP (Vtransient_mark_mode)
>                    && EQ (XCAR (Vtransient_mark_mode), Qonly))
>             call1 (Qhandle_shift_selection, Qt);       <================
>           string++;
>         }
> .

I see.  I guess we just disagree on what is meant by "hardcoded in the
command loop": this code is explicitly requested by the "^" code in the
`interactive' string of a command, so it seems (to me) pretty far from
"hardcoded in the command loop".


        Stefan

Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode]

[Alan Mackenzie]

Hi, Stefan,

On Tue, Mar 24, 2009 at 09:38:29PM -0400, Stefan Monnier wrote:
> >> Where do you see it hardcoded in the command loop?

> > In Fcall_interactively, Lines 207 and 231, where it is interpreting the
> > interactive string:

> >       else if (*string == '^')
> >         {
> >           if (! NILP (Vshift_select_mode))
> >              call1 (Qhandle_shift_selection, Qnil);    <================
> >           /* Even if shift-select-mode is off, temporarily active
> >              regions could be set using the mouse, and should be
> >              deactivated.  */
> >           else if (CONSP (Vtransient_mark_mode)
> >                    && EQ (XCAR (Vtransient_mark_mode), Qonly))
> >             call1 (Qhandle_shift_selection, Qt);       <================
> >           string++;
> >         }
> > .

> I see.  I guess we just disagree on what is meant by "hardcoded in the
> command loop": this code is explicitly requested by the "^" code in the
> `interactive' string of a command, so it seems (to me) pretty far from
> "hardcoded in the command loop".

It's hard-coded to the shift-key, rather than using the normal Emacs
mechanism of putting the "shifted" versions of movement commands into a
minor mode map.  Interactive strings which use "^" are incompatible with
other Emacs versions.  This will cause problems.

How is an external library writer going to use the interactive "^"?
Assuming that the library should also work under XEmacs and Emacs 22,
just using the "^" won't work; an interactive string with "^" throws an
error in Emacs 22.

The next try is to use a macro which will generate an appropriate
interactive string.  Something like:
    
    (defmacro foo-interactive (s-22 s-23)
       "doc string"
       `(interactive ,(if (emacs-got-interactive-hat) s-23 s22)))

, but I can't get defun to take a macro-generated interactive string.  I
suspect it's not possible.  It seems to work, sort of, in byte-compiled
defuns.

Could we supply some sort of macro which will add "^" to an interactive
string?  Then at least each external library author won't have to figure
it out himself.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> How is an external library writer going to use the interactive "^"?
> Assuming that the library should also work under XEmacs and Emacs 22,
> just using the "^" won't work; an interactive string with "^" throws an
> error in Emacs 22.

Isn't that a pretty basic problem with _any_ extension to interactive?
Do you think `interactive' should never be extended?

In this case, I think the right solution would be to simply add another,
possibly clunkier method for commands to indicate they want to enable
shift-selection behavior.

E.g.: have the command loop also look for a `handle-shift-select'
property on command-name's plist, and treat that as it would "^" in the
interactive string.  Then external library authors who are worried about
backwards compability could use (put COMMAND 'handle-shift-select t)
instead of putting ^ in COMMAND's interactive string.

[Yeah, that only works for commands which are defined functions, but I
think that's an acceptable limitation for a feature like this which
should be used only rarely.]

-Miles

-- 
"1971 pickup truck; will trade for guns"

Re: Interactive hat.

[Alan Mackenzie]

Hi, Miles!

On Wed, Mar 25, 2009 at 07:30:13PM +0900, Miles Bader wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > How is an external library writer going to use the interactive "^"?
> > Assuming that the library should also work under XEmacs and Emacs 22,
> > just using the "^" won't work; an interactive string with "^" throws an
> > error in Emacs 22.

> Isn't that a pretty basic problem with _any_ extension to interactive?
> Do you think `interactive' should never be extended?

Yes, and yes.  Or, rather, yes and yes except in the most exceptional of
circumstances, such as adding a new parameter type.

> In this case, I think the right solution would be to simply add another,
> possibly clunkier method for commands to indicate they want to enable
> shift-selection behavior.

Agreed.

> E.g.: have the command loop also look for a `handle-shift-select'
> property on command-name's plist, and treat that as it would "^" in the
> interactive string.  Then external library authors who are worried about
> backwards compability could use (put COMMAND 'handle-shift-select t)
> instead of putting ^ in COMMAND's interactive string.

Agreed, except I wouldn't put it in the command loop - I'd put it in a
hook (pre-command-hook), for the same reason font-locking is in a hook
rather than directly in the command loop.  M-x shift-select would
install/remove this function onto/from the hook.

Now the question arises, if we've got the property
`handle-shift-select', doesn't the "^" in the interactive string become
redundant?

> [Yeah, that only works for commands which are defined functions, but I
> think that's an acceptable limitation for a feature like this which
> should be used only rarely.]

Yes, a lambda expression can't use this.  That's the only use of "^" I
can see which absolutely requires "^".  But let's be honest, how often
do hackers write movement commands as anonymous lambdas?

> -Miles

> -- 
> "1971 pickup truck; will trade for gnus"

Hey, you can get gnus for nothing.  :-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Lennart Borgman]

Hi Alan,

On Wed, Mar 25, 2009 at 11:53 AM, Alan Mackenzie <acm@muc.de> wrote:
> Agreed, except I wouldn't put it in the command loop - I'd put it in a
> hook (pre-command-hook), for the same reason font-locking is in a hook
> rather than directly in the command loop.  M-x shift-select would
> install/remove this function onto/from the hook.

We discussed this before and my conclusion was that this would not
work well enough because of the order of things in the hook would be
crucial. I suggested adding a new hook to run before pre-command-hook.
(And something similar for pos-command-hook.)

Re: Interactive hat.

[Alan Mackenzie]

Hi, Lennart!

On Wed, Mar 25, 2009 at 12:03:08PM +0100, Lennart Borgman wrote:
> Hi Alan,

> On Wed, Mar 25, 2009 at 11:53 AM, Alan Mackenzie <acm@muc.de> wrote:
> > Agreed, except I wouldn't put it in the command loop - I'd put it in a
> > hook (pre-command-hook), for the same reason font-locking is in a hook
> > rather than directly in the command loop.  M-x shift-select would
> > install/remove this function onto/from the hook.

> We discussed this before and my conclusion was that this would not
> work well enough because of the order of things in the hook would be
> crucial. I suggested adding a new hook to run before pre-command-hook.
> (And something similar for pos-command-hook.)

Yes, I remember that discussion.  ;-)  It was about a year ago.  I'll go
and look it up, and see what you said.

Thanks for the pointer!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Alan Mackenzie]

Hi again, Lennart!

On Wed, Mar 25, 2009 at 12:03:08PM +0100, Lennart Borgman wrote:
> Hi Alan,

> On Wed, Mar 25, 2009 at 11:53 AM, Alan Mackenzie <acm@muc.de> wrote:
> > Agreed, except I wouldn't put it in the command loop - I'd put it in a
> > hook (pre-command-hook), for the same reason font-locking is in a hook
> > rather than directly in the command loop.  M-x shift-select would
> > install/remove this function onto/from the hook.

> We discussed this before and my conclusion was that this would not
> work well enough because of the order of things in the hook would be
> crucial. I suggested adding a new hook to run before pre-command-hook.
> (And something similar for pos-command-hook.)

I've searched the archive from a year ago, looking at your posts which
contain the word "hook".  You've certainly asserted that the order of
functions in the pre-command-hook is important, but I don't think you
gave any concrete examples of where an unfortunate ordering would mess
things up.  I think you were thinking of things like Viper Mode, and the
use of commands like `d' (for delete) combined with, say `)' (for end of
sentence).

In my experience, these feelings of unease are usually justified.  ;-)
All the same, could you possibly construct a realistic example of two
functions in pre-command-hook which work properly in one order, but foul
up in the other?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
> Now the question arises, if we've got the property
> `handle-shift-select', doesn't the "^" in the interactive string become
> redundant?

Not at all.  For the vast majority of uses -- functions distributed with
emacs (and in external packages that don't care about xemacs or older
versions of emacs), it's more convenient and prettier.

-Miles

-- 
Accord, n. Harmony.

Re: Interactive hat.

[Alan Mackenzie]

Hi, Miles!

On Wed, Mar 25, 2009 at 11:59:58PM +0900, Miles Bader wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > Now the question arises, if we've got the property
> > `handle-shift-select', doesn't the "^" in the interactive string become
> > redundant?

> Not at all.  For the vast majority of uses -- functions distributed with
> emacs (and in external packages that don't care about xemacs or older
> versions of emacs), it's more convenient and prettier.

It is, perhaps, more convenient, but prettier?  Well, let's just say
that it is possible to take different viewpoints on this.  Mine is that
it's an ugly hack, utterly different from anything that's gone before,
and it will have negative implications, not all of which will be
foreseen before the release of Emacs 23.  I think it's more "clever"
than smart, a bit like C++'s abuse of the shift-left operator:

    cout << (byte_count << 3) ;

.  Somebody will end up having to code round it.  

If it's possible to code everything we need with a symbol property, I
think the interactive hat mechanism should be removed.

There are currently only 28 defuns (in simple.el, lisp.el and
paragraphs.el) which use this, so changing them to use a property
instead would be a trivial amount of work.

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> On Wed, Mar 25, 2009 at 11:59:58PM +0900, Miles Bader wrote:
>> Alan Mackenzie <acm@muc.de> writes:
>> > Now the question arises, if we've got the property
>> > `handle-shift-select', doesn't the "^" in the interactive string become
>> > redundant?
>
>> Not at all.  For the vast majority of uses -- functions distributed with
>> emacs (and in external packages that don't care about xemacs or older
>> versions of emacs), it's more convenient and prettier.
>
> It is, perhaps, more convenient, but prettier?  Well, let's just say
> that it is possible to take different viewpoints on this.  Mine is that
> it's an ugly hack, utterly different from anything that's gone before,
> and it will have negative implications, not all of which will be
> foreseen before the release of Emacs 23.  I think it's more "clever"
> than smart, a bit like C++'s abuse of the shift-left operator:
>
>     cout << (byte_count << 3) ;
>
> .  Somebody will end up having to code round it.  
>
> If it's possible to code everything we need with a symbol property, I
> think the interactive hat mechanism should be removed.
>
> There are currently only 28 defuns (in simple.el, lisp.el and
> paragraphs.el) which use this, so changing them to use a property
> instead would be a trivial amount of work.

You can't put a symbol property on an anonymous function, and quite a
few interactive functions are autogenerated within Emacs, particularly
in mouse keymaps.

-- 
David Kastrup

Re: Interactive hat.

[Alan Mackenzie]

Hi, David!

On Thu, Mar 26, 2009 at 01:14:21PM +0100, David Kastrup wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > If it's possible to code everything we need with a symbol property, I
> > think the interactive hat mechanism should be removed.

> > There are currently only 28 defuns (in simple.el, lisp.el and
> > paragraphs.el) which use this, so changing them to use a property
> > instead would be a trivial amount of work.

> You can't put a symbol property on an anonymous function, and quite a
> few interactive functions are autogenerated within Emacs, particularly
> in mouse keymaps.

Could you point out an example of this, please?

Do any of these autogenerated commands use interactive-hat?  Would it be
practical and not too ugly to amend these commands to use a symbol,
possibly not interned?

Does shift-select-mode even make any sense for mouse commands?  (I'm not
a mouse user.)

> -- 
> David Kastrup

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Stefan Monnier]

> If it's possible to code everything we need with a symbol property, I
> think the interactive hat mechanism should be removed.

You got things backwards here: the "^" describes the behavior of the
command, so it should be part of the command, not its name.  The ability
to use a symbol property for that is a hack that can come in handy at
times, but it's still just a hack.


        Stefan

Re: Interactive hat.

[Alan Mackenzie]

Hi, Stefan!

On Thu, Mar 26, 2009 at 09:48:11AM -0400, Stefan Monnier wrote:
> > If it's possible to code everything we need with a symbol property, I
> > think the interactive hat mechanism should be removed.

> You got things backwards here: the "^" describes the behavior of the
> command, so it should be part of the command, not its name.

NOT SO FAST THERE, BUDDY!!!  Most, possibly nearly all, properties
attached to a symbol describe either the symbol-function or the
symbol-value.  So, whilst I agree you have some sort of point, it would
require a massive change to Emacs Lisp to allow properties to be
attached to a function or value, as opposed to the symbol holding them.

> The ability to use a symbol property for that is a hack that can come
> in handy at times, but it's still just a hack.

I don't think so.  It is the standard canonical use of symbol
properties.  A quick bit of grepping reveals 4278 uses of `put'.  Of the
ones in the first 100 or so, they all look recording properties of the
function rather than the symbol itself.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Stefan Monnier]

>> The ability to use a symbol property for that is a hack that can come
>> in handy at times, but it's still just a hack.

> I don't think so.  It is the standard canonical use of symbol
> properties.  A quick bit of grepping reveals 4278 uses of `put'.  Of the
> ones in the first 100 or so, they all look recording properties of the
> function rather than the symbol itself.

And they're all hacks (some of them a bit less so because the property
is actually installed as part of the symbol's definition (I'm thinking
of the `declare' thingy in macros used to set the indent and edebug
properties).


        Stefan

Re: Interactive hat.

[Alan Mackenzie]

Hi, Stefan!

On Thu, Mar 26, 2009 at 12:30:38PM -0400, Stefan Monnier wrote:
> >> The ability to use a symbol property for that is a hack that can come
> >> in handy at times, but it's still just a hack.

> > I don't think so.  It is the standard canonical use of symbol
> > properties.  A quick bit of grepping reveals 4278 uses of `put'.  Of the
> > ones in the first 100 or so, they all look recording properties of the
> > function rather than the symbol itself.

> And they're all hacks (some of them a bit less so because the property
> is actually installed as part of the symbol's definition (I'm thinking
> of the `declare' thingy in macros used to set the indent and edebug
> properties).

Well, what can one say?  The property list is part of a symbol.  The
other parts are its name, its function and its value.  If it's a hack for
a property to describe the function, it's just as much a hack for the
property to describe the value.  So a property describes either the
property list (which is non-sensical) or the name, or the property is
free-standing.

So I think you're arguing that a property can only properly describe the
name part of a symbol.

Or, maybe, just maybe, using properties in the customary way isn't such a
bad hack after all.  :-)

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Stefan Monnier]

> So I think you're arguing that a property can only properly describe the
> name part of a symbol.

Yes.

> Or, maybe, just maybe, using properties in the customary way isn't such a
> bad hack after all.  :-)

They're convenient hacks.  But when the property can be put directly on
the object, it's usually preferable.


        Stefan

Re: Interactive hat.

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> So I think you're arguing that a property can only properly describe the
>> name part of a symbol.
>
> Yes.
>
>> Or, maybe, just maybe, using properties in the customary way isn't such a
>> bad hack after all.  :-)
>
> They're convenient hacks.  But when the property can be put directly on
> the object, it's usually preferable.

Based on my years of experience with CUA-mode, I fully agree with Alan.
Using symbol property + dedicated pre/post hooks is IMHO superior to
interactive-hat for several reasons (that I gave a long time ago).

But I've given up that battle - as long as CUA-mode seems to keep working
despite the ^ thingy, I'm indifferent to how its done in "standard" emacs.

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

Re: Interactive hat.

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Based on my years of experience with CUA-mode, I fully agree with Alan.
> Using symbol property + dedicated pre/post hooks is IMHO superior to
> interactive-hat for several reasons (that I gave a long time ago).

I don't think the giant glutinous mess that is CUA-mode is a
particularly compelling example...

-Miles

-- 
Accord, n. Harmony.

Re: Interactive hat.

[Lennart Borgman]

On Sun, Mar 29, 2009 at 2:40 AM, Miles Bader <miles@gnu.org> wrote:
> storm@cua.dk (Kim F. Storm) writes:
>> Based on my years of experience with CUA-mode, I fully agree with Alan.
>> Using symbol property + dedicated pre/post hooks is IMHO superior to
>> interactive-hat for several reasons (that I gave a long time ago).
>
> I don't think the giant glutinous mess that is CUA-mode is a
> particularly compelling example...

Why not? Kim gave reasons.

Re: Interactive hat.

[Stephen J. Turnbull]

Stefan Monnier writes:
 > > If it's possible to code everything we need with a symbol property, I
 > > think the interactive hat mechanism should be removed.
 >
 > You got things backwards here: the "^" describes the behavior of
 > the command, so it should be part of the command, not its name.

In XEmacs, both descriptions are incorrect.  "Shifted motion selects"
is a property of the key, not of the command nor of its name.

 > The ability to use a symbol property for that is a hack that can
 > come in handy at times, but it's still just a hack.

XEmacs has used a variable containing a list of key names that might
have this behavior for ten years with no apparent ill-effects.  And it
similarly has been hard-coded to the shift key for ten years with no
apparent ill-effects.

Re: Interactive hat.

[Miles Bader]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:
>  > You got things backwards here: the "^" describes the behavior of
>  > the command, so it should be part of the command, not its name.
>
> In XEmacs, both descriptions are incorrect.  "Shifted motion selects"
> is a property of the key, not of the command nor of its name.

Er, so if I rebind "C-f" to some command in my mode which is completely
unrelated to the default binding, does it still inherit the default
shifted-select feature?!  What if I rebind some other key to
"forward-char"?  Does that new binding then lack shifted-select?

[If so -- wacky...]

-Miles

-- 
Christian, n. One who follows the teachings of Christ so long as they are not
inconsistent with a life of sin.

Re: Interactive hat.

[Stephen J. Turnbull]

Miles Bader writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:

 > > In XEmacs [...] "shifted motion selects" is a property of the
 > > key, not of the command nor of its name.
 > 
 > Er, so if I rebind "C-f" to some command in my mode which is completely
 > unrelated to the default binding, does it still inherit the default
 > shifted-select feature?!

No, because by default C-f isn't in the list.  The default list
contains the arrow keys and the motion keys on the keypad, along with
certain combinations of those keys with other modifiers.

So let's talk about rebinding 'right instead.  If by "unrelated" you
mean "not a motion command", then the answer is "yes, but you'll never
know the difference."  If by "unrelated" you mean something else
(what?), the answer is "yes, and the difference is observable if and
only if the new binding is a motion command".

 > What if I rebind some other key to "forward-char"?  Does that new
 > binding then lack shifted-select?

Yes.  In fact, if (as is most probably the case) you have both 'right
and C-f bound to `forward-char', then (by default) 'right has the
property and C-f does not.

 > [If so -- wacky...]

Only because you buy in to Stefan's notion that this is a property of
the command rather than of the key binding.  But talk about wacky
hacks! if it's a property of the command, why does the command need to
inspect the key binding to figure out what to do?  If taken seriously,
that implies Alan's right about defining a separate motion command
with shift-motion-selects behavior.

BTW, this was a key[sic] strategy to get shifted-motion-selects past
Ye Olde Guard who detested CUA.  Ye Olde Guard don't use no steenkin'
arrows (IIRC some versions of the Happy Hacker keyboard don't have
arrows at all).  It doesn't bother the Windows Volk either, since they
are usually a bit upset that C-f doesn't invoke Find. ;-)

Cheers!

Re: Interactive hat.

[Stefan Monnier]

>> How is an external library writer going to use the interactive "^"?
>> Assuming that the library should also work under XEmacs and Emacs 22,
>> just using the "^" won't work; an interactive string with "^" throws an
>> error in Emacs 22.
> Isn't that a pretty basic problem with _any_ extension to interactive?

Indeed.

> Do you think `interactive' should never be extended?

Indeed no.

> In this case, I think the right solution would be to simply add another,
> possibly clunkier method for commands to indicate they want to enable
> shift-selection behavior.

It needs to be easy to translate any `interactive' string into an
`interactive' Elisp expression.  Currently, that's not always the case,
and I think it's a problem that needs to be solved.
If you start with an `interactive' string and later need to add an
argument which needs fancier treatment, you sometimes end up struggling
to find an equivalent Elisp form for each of your arguments.

Yes, this is indeed a problem.  Of course, not specific to "^".

If someone were to rewrite `call-interactive' such that it comes with
a alist associating each char-code to the corresponding Elisp
expression, that would be very helpful (and we could then even provide
a command in emacs-lisp-mode to automatically turn a (interactive "foo")
into (interactive (blabla))).


        Stefan

Re: Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode]

[Juanma Barranquero]

On Wed, Mar 25, 2009 at 11:16, Alan Mackenzie <acm@muc.de> wrote:

> The next try is to use a macro which will generate an appropriate
> interactive string.  Something like:
>
>    (defmacro foo-interactive (s-22 s-23)
>       "doc string"
>       `(interactive ,(if (emacs-got-interactive-hat) s-23 s22)))
>
> , but I can't get defun to take a macro-generated interactive string.  I
> suspect it's not possible.  It seems to work, sort of, in byte-compiled
> defuns.

It is not possible to use the `interactive-form' symbol property, as
documented in (elisp)"21.2.1 Using `interactive'" ?

    Juanma

Re: Interactive hat.

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> It is not possible to use the `interactive-form' symbol property, as
> documented in (elisp)"21.2.1 Using `interactive'" ?

I think we have a winner.

Re: Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode]

[Alan Mackenzie]

Hi, Juanma,

On Wed, Mar 25, 2009 at 12:26:58PM +0100, Juanma Barranquero wrote:
> On Wed, Mar 25, 2009 at 11:16, Alan Mackenzie <acm@muc.de> wrote:

> > The next try is to use a macro which will generate an appropriate
> > interactive string.  Something like:

> >   (defmacro foo-interactive (s-22 s-23)
> >       "doc string"
> >       `(interactive ,(if (emacs-got-interactive-hat) s-23 s22)))

> > , but I can't get defun to take a macro-generated interactive string.  I
> > suspect it's not possible.  It seems to work, sort of, in byte-compiled
> > defuns.

> It is not possible to use the `interactive-form' symbol property, as
> documented in (elisp)"21.2.1 Using `interactive'" ?

I don't think so.  `interactive-form' is a DEFUN (in data.c) which hoiks
the interactive string out of three different places for three different
sorts of defun.  There's currently no `put-interactive-form', but
there's no reason why one couldn't be written.

>     Juanma

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode]

[Juanma Barranquero]

On Wed, Mar 25, 2009 at 15:19, Alan Mackenzie <acm@muc.de> wrote:

> I don't think so.  `interactive-form' is a DEFUN (in data.c) which hoiks
> the interactive string out of three different places for three different
> sorts of defun.

I don't think I'm understanding you. I'm talking about the
`interactive-form' symbol property, not the `interactive-form'
function. I.e.:

     The `interactive' form must be located at top-level in the
     function body, or in the function symbol's `interactive-form'
     property (*note Symbol Plists::).  It has its effect because the
     command loop looks for it before calling the function (*note
     Interactive Call::).  Once the function is called, all its body
     forms are executed; at this time, if the `interactive' form occurs
     within the body, the form simply returns `nil' without even
     evaluating its argument.

ELISP> (defun test (&optional arg) (message "Arg = %S" arg))
test
ELISP> (commandp 'test)
nil
ELISP> (put 'test 'interactive-form '(interactive "p"))
(interactive "p")

ELISP> (commandp 'test)
t
ELISP> (call-interactively #'test)
"Arg = 1"
ELISP>

> There's currently no `put-interactive-form', but
> there's no reason why one couldn't be written.

What does that gain over (put SYMBOL 'interactive-form INTERACTIVE-SPEC) ?

    Juanma

Re: Interactive hat. [Was: CUA-like stuff spuriously enables transient-mark-mode]

[Alan Mackenzie]

Hi, Juanma,

On Wed, Mar 25, 2009 at 05:41:01PM +0100, Juanma Barranquero wrote:
> On Wed, Mar 25, 2009 at 15:19, Alan Mackenzie <acm@muc.de> wrote:

> > I don't think so.  `interactive-form' is a DEFUN (in data.c) which hoiks
> > the interactive string out of three different places for three different
> > sorts of defun.

> I don't think I'm understanding you. I'm talking about the
> `interactive-form' symbol property, not the `interactive-form'
> function. I.e.:
> 
>      The `interactive' form must be located at top-level in the
>      function body, or in the function symbol's `interactive-form'
>      property (*note Symbol Plists::).  It has its effect because the
>      command loop looks for it before calling the function (*note
>      Interactive Call::).  Once the function is called, all its body
>      forms are executed; at this time, if the `interactive' form occurs
>      within the body, the form simply returns `nil' without even
>      evaluating its argument.

Sorry, I wasn't aware of this property.  It does indeed work, but ONLY
in Emacs 23.

[ .... ]

> > There's currently no `put-interactive-form', but there's no reason
> > why one couldn't be written.

> What does that gain over (put SYMBOL 'interactive-form INTERACTIVE-SPEC) ?

The source for such a function, `put-interactive-form' assuming we could
write it in lisp, could be printed in the elisp manual (page "Using
Interactive"), and the maintainer of Foo Mode encouraged to copy it into
her package and use it to maintain compatibility with older Emacsen and
XEmacs, thusly:

    (defun foo-forward-blag (arg)
      "Move forward to the end of the current blag, ...."
      (interactive "^P") .....)
    (if (not emacs-23) (put-interactive-form 'foo-forward-blag "P"))

Alternatively, we could recommend package maintainers not to use "^"
directly in interactive strings, instead only putting them in the
`interactive-form' property.  But this kind of makes the "^" look
contrived and kludgey.

If we're going to be keeping interactive-hat, I think we definitely need
some sort of warning to package maintainers to be careful with it, and we
should offer them a recipe for maintaining compatibility.

>     Juanma

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Stefan Monnier]

> If we're going to be keeping interactive-hat, I think we definitely need
> some sort of warning to package maintainers to be careful with it, and we
> should offer them a recipe for maintaining compatibility.

I think you're blinded by your hatred of this (mis)feature.
It has nothing particularly more special than any other new feature
we introduced.

Yes, if people use it, they get backward compatibility problems.
So what?


        Stefan

Re: Interactive hat.

[Alan Mackenzie]

Hi, Stefan!

On Thu, Mar 26, 2009 at 09:50:27AM -0400, Stefan Monnier wrote:
> > If we're going to be keeping interactive-hat, I think we definitely need
> > some sort of warning to package maintainers to be careful with it, and we
> > should offer them a recipe for maintaining compatibility.

> I think you're blinded by your hatred of this (mis)feature.

Yes, I hate this feature.  But rather than blinding me, this has opened
my eyes to its problems, and I am thus motivated to root them out.  By
contrast, those who like the feature will be blind to these problems.

> It has nothing particularly more special than any other new feature
> we introduced.

Sorry, I disagree.

> Yes, if people use it, they get backward compatibility problems.
> So what?

OK, I'm speaking here as a representative of external package
maintainers, even if not elected.

I don't feel it's appropriate to be so cavalier with external hackers'
time and effort.  More than once, in the past 8 or 9 years, I've asked
myself "what were these idiots thinking about when they implemented
this?".  It's not good to encourage package maintainers to think of the
Emacs core team as idiots, especially since I've become one myself ;-).

It is not a good use of hackers' time and energy to keep reinventing the
wheel.  It isn't fun working round incompatibilities between various
(X)Emacs versions.  Really it isn't.  It's boring, it's drudgery, isn't
at all creative, saps enthusiasm and it diverts effort from adding new
snazzy features.

This particular feature is an order of magnitude nastier to field than
most.  A typical conscientious package maintainer is going to go through
all the thoughts that we've posting on emacs-devel, and most of the time
will come up with some sub-optimal half-solution.  Probably, they'll
just decide not to use "^".  At the end of it all, a weekend's hacking
time per hacker has been lost.

#########################################################################

Anyhow, I've discovered that this problem is not new, and it's already
been solved.  XEmacs put a "_" into their interactive string long ago,
and there's a macro `defunx' in antlr-mode.el which, when used in place
of `defun', strips out the "_" from an interactive string; OK, it does a
few other things, too.

How about adapting this macro and putting it into a special source file
in .../lisp/, and making a discreet mention of it in "Using Interactive"
in the elisp manual?  For example: "Note that using \"^\" will prevent
your function running in older Emacs versions.  If you need this
compatibility, consider using the macro `defunh' in the file
lisp/compatibility.el.".

I would far rather put the work in here and now than have to field
complaints on bug-cc-mode in a year's time, asking why the CC Mode
commands don't work with shift-select-mode.

So, how about it?  This solution will leave interactive-hat, as it is
currently implemented, untouched, and it will stop me moaning about it
for ever.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Stefan Monnier]

> Yes, I hate this feature.  But rather than blinding me, this has opened
> my eyes to its problems, and I am thus motivated to root them out.  By
> contrast, those who like the feature will be blind to these problems.

The feature is a result of a long and painful process.  I have no
intention to go through it again.  I think the result is pretty clean,
so I'm not open to changing it, except for minor aspects.

> Anyhow, I've discovered that this problem is not new, and it's already
> been solved.  XEmacs put a "_" into their interactive string long ago,
> and there's a macro `defunx' in antlr-mode.el which, when used in place
> of `defun', strips out the "_" from an interactive string; OK, it does a
> few other things, too.

> How about adapting this macro and putting it into a special source file
> in .../lisp/, and making a discreet mention of it in "Using Interactive"
> in the elisp manual?  For example: "Note that using \"^\" will prevent
> your function running in older Emacs versions.  If you need this
> compatibility, consider using the macro `defunh' in the file
> lisp/compatibility.el.".

> I would far rather put the work in here and now than have to field
> complaints on bug-cc-mode in a year's time, asking why the CC Mode
> commands don't work with shift-select-mode.

> So, how about it?  This solution will leave interactive-hat, as it is
> currently implemented, untouched, and it will stop me moaning about it
> for ever.

What about my other suggestion to make it available to interactive
specs using a Lisp form rather than a string?  That would seem a lot
simpler and cleaner.

So, I've indeed done that, which incidentally simplifies the code.
Now inserting a "^" in the interactive string is just the same as
calling (handle-shift-selection), so you can write

  (interactive
   (progn (if (fboundp 'handle-shift-selection) (handle-shift-selection))
          ...blabla...))


-- Stefan

Re: Interactive hat.

[Alan Mackenzie]

Hi, Stefan!

On Thu, Mar 26, 2009 at 01:09:48PM -0400, Stefan Monnier wrote:
> > Yes, I hate this feature.  But rather than blinding me, this has
> > opened my eyes to its problems, and I am thus motivated to root them
> > out.  By contrast, those who like the feature will be blind to these
> > problems.

> The feature is a result of a long and painful process.  I have no
> intention to go through it again.  I think the result is pretty clean,
> so I'm not open to changing it, except for minor aspects.

The process was painful in the extreme, I remember it well.  I don't want
to go through it again either.  I'm confident that my suggestion below
doesn't change the status quo; it justs adds a facility for external
maintainers.

> > Anyhow, I've discovered that this problem is not new, and it's
> > already been solved.  XEmacs put a "_" into their interactive string
> > long ago, and there's a macro `defunx' in antlr-mode.el which, when
> > used in place of `defun', strips out the "_" from an interactive
> > string; OK, it does a few other things, too.

> > How about adapting this macro and putting it into a special source
> > file in .../lisp/, and making a discreet mention of it in "Using
> > Interactive" in the elisp manual?  For example: "Note that using
> > \"^\" will prevent your function running in older Emacs versions.  If
> > you need this compatibility, consider using the macro `defunh' in the
> > file lisp/compatibility.el.".

> > I would far rather put the work in here and now than have to field
> > complaints on bug-cc-mode in a year's time, asking why the CC Mode
> > commands don't work with shift-select-mode.

> > So, how about it?  This solution will leave interactive-hat, as it is
> > currently implemented, untouched, and it will stop me moaning about it
> > for ever.

> What about my other suggestion to make it available to interactive
> specs using a Lisp form rather than a string?  That would seem a lot
> simpler and cleaner.

I'm assuming an external package maintainer wanting to use (interactive
"^P\nr"), still have the command work in Emacs <23 and XEmacs, yet not
have to waste time working out for herself how to achieve this.  I think
I might have misunderstood your suggestion.

> So, I've indeed done that, which incidentally simplifies the code.
> Now inserting a "^" in the interactive string is just the same as
> calling (handle-shift-selection), so you can write

>   (interactive
>    (progn (if (fboundp 'handle-shift-selection) (handle-shift-selection))
>           ...blabla...))

No, that's not simpler or clearer.  It's just pushing the work onto the
package maintainer.  And it's a LOT of work.  For example,

    (interactive "^P\nr")

becomes

    (interactive
      (progn (if (fboundp 'handle-shift-selection)
                 (handle-shift-selection))
             `(current-prefix-arg
	       ,(if (< (point) (mark))
	            ,@((point) (mark))
		  ,@((mark) (point))))))

, or something equally repulsive, requiring infinitely more debugging
than the string it replaces.  My proposal is to suggest to the maintainer
she copy the macro from .../lisp/compatibility.el into her own sources,
rename it `foo-defunh'[*] and write:

[*] think of this as a hyperbolic defun. ;-)

  (foo-defunh foo-forward-blarg (arg beg end) "..." (interactive "^P\nr") ....)

Although there's a certain tedium involved in that suggestion, it's a
straightforward recipe that doesn't require thinking.

> -- Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Stefan Monnier]

> No, that's not simpler or clearer.  It's just pushing the work onto the
> package maintainer.  And it's a LOT of work.  For example,

>     (interactive "^P\nr")

> becomes

>     (interactive
>       (progn (if (fboundp 'handle-shift-selection)
>                  (handle-shift-selection))
>              `(current-prefix-arg
> 	       ,(if (< (point) (mark))
> 	            ,@((point) (mark))
> 		  ,@((mark) (point))))))

Yes, that's because "r" hasn't yet received the treatment I just gave to
"^".  As explained in my message of a couple days ago, it should always
be easy to turn an interactive string into the corresponding lisp form.

> , or something equally repulsive, requiring infinitely more debugging
> than the string it replaces.

Actually, in all likelyhood,

    (interactive
      (progn (if (fboundp 'handle-shift-selection)
                 (handle-shift-selection))
             (list current-prefix-arg (point) (mark))))

will work just fine (in 99% of the cases, the subsequent code has to
figure out anyway whether `start' is indeed before `end' in case the
function is called from Lisp rather than interactively).
So you're exaggerating a little bit.

> My proposal is to suggest to the maintainer she copy the macro from
> .../lisp/compatibility.el into her own sources, rename it
> `foo-defunh'[*] and write:

Feel free to recommend it.  I find it hideous.


        Stefan

Re: Interactive hat.

[Johan Bockgård]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>              (list current-prefix-arg (point) (mark))))

region-beginning/region-end

Re: Interactive hat.

[Alan Mackenzie]

Hi, Johan!

On Thu, Mar 26, 2009 at 11:32:42PM +0100, Johan Bockgård wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >              (list current-prefix-arg (point) (mark))))

> region-beginning/region-end

Thanks for that!  It's so easy to lose track of the obvious in the heat
of debate.

-- 
Alan Mackenzie (Nuremberg, Germany)

Re: Interactive hat.

[Alan Mackenzie]

Hi, Stefan!

On Thu, Mar 26, 2009 at 05:18:05PM -0400, Stefan Monnier wrote:
> > No, that's not simpler or clearer.  It's just pushing the work onto the
> > package maintainer.  And it's a LOT of work.  For example,

> >     (interactive "^P\nr")

> > becomes

> >     (interactive
> >       (progn (if (fboundp 'handle-shift-selection)
> >                  (handle-shift-selection))
> >              `(current-prefix-arg
> > 	       ,(if (< (point) (mark))
> > 	            ,@((point) (mark))
> > 		  ,@((mark) (point))))))

> Yes, that's because "r" hasn't yet received the treatment I just gave
> to "^".  As explained in my message of a couple days ago, it should
> always be easy to turn an interactive string into the corresponding
> lisp form.

> > , or something equally repulsive, requiring infinitely more debugging
> > than the string it replaces.

> Actually, in all likelyhood,

>     (interactive
>       (progn (if (fboundp 'handle-shift-selection)
>                  (handle-shift-selection))
>              (list current-prefix-arg (point) (mark))))

OK, perhaps I was exaggerating a bit.

> will work just fine (in 99% of the cases, the subsequent code has to
> figure out anyway whether `start' is indeed before `end' in case the
> function is called from Lisp rather than interactively).  So you're
> exaggerating a little bit.

I think we'd both go with Johan's (region-beginning) and (region-end).

> > My proposal is to suggest to the maintainer she copy the macro from
> > .../lisp/compatibility.el into her own sources, rename it
> > `foo-defunh'[*] and write:

> Feel free to recommend it.  I find it hideous.

Actually I'm rather surprised about that.  But as I said, my main aim
here is to minimise the time and mental effort the change will cause
package maintainers.

How about I take your suggestion as meaning that page "Interactive Codes"
should be enhanced to give the lisp equivalent for each code letter, and
it is made clear that the string version is a convenient abbreviation
which works nearly all the time, and the lisp code is the fully general
version?

I could even write a patch.  Just not tonight.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat.

[Stefan Monnier]

> How about I take your suggestion as meaning that page "Interactive Codes"
> should be enhanced to give the lisp equivalent for each code letter, and
> it is made clear that the string version is a convenient abbreviation
> which works nearly all the time, and the Lisp code is the fully general
> version?

That's the idea, yes.  Additionally, the equivalent Lisp code should be
simple (a single funcall), which isn't always possible right now, IIRC.


        Stefan

Re: Interactive hat.

[Alan Mackenzie]

Hi, Stefan,

On Thu, Mar 26, 2009 at 10:50:11PM -0400, Stefan Monnier wrote:
> > How about I take your suggestion as meaning that page "Interactive
> > Codes" should be enhanced to give the lisp equivalent for each code
> > letter, and it is made clear that the string version is a convenient
> > abbreviation which works nearly all the time, and the Lisp code is
> > the fully general version?

> That's the idea, yes.  Additionally, the equivalent Lisp code should
> be simple (a single funcall), which isn't always possible right now,
> IIRC.

OK, I'll get on with that.  Hopefully, I'll post a patch to
commands.texi in the next few days.

Thanks for all the arguments!

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).