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

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. [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.

[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.

[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.

[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 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.

[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.

[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. [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.

[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.

[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: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.

[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.

[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]

>> 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]

> 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.

[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]

> 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.

[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, 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.

[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.

[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 --]

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).

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. (Patch)

[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, here's the patch.  In the end, I put all these lisp forms into a new
page "Non-string Interactive" because it seemed better balanced.

I think that the order of "*" and "@" in (interactive "@*") matters.
Well, it would matter if there were any commands which use them both;
there aren't in Emacs.

It's a fairly hefty patch, so any review/criticism would be welcome.



2009-04-13  Alan Mackenzie  <acm@muc.de>

	* elisp.texi (Top): Add menu entry for "Non-string Interactive".

	* commands.texi (Using Interactive): Amend description of string
	form of interactive form.  Rectify false statement that the order
	of "special" characters is immaterial.  Insert a `*' into the
	example.  Give a rationale for existence of string form, and imply
	a non-string form is more general.  Remove redundant definitions
	of `*', `@' and `^'.
	(Interactive Codes): Insert an introduction.  Expand the
	descriptions of `@' and `^', including details formerly in "Using
	Interactive".
	(Non-string Interactive): New page giving non-string equivalents
	for all code characters.
	(Interactive Examples): Add a space after the prompts' colons.




Index: elisp.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/doc/lispref/elisp.texi,v
retrieving revision 1.34
diff -c -r1.34 elisp.texi
*** elisp.texi	9 Apr 2009 01:17:10 -0000	1.34
--- elisp.texi	13 Apr 2009 19:31:09 -0000
***************
*** 662,667 ****
--- 662,668 ----
  * Using Interactive::       General rules for @code{interactive}.
  * Interactive Codes::       The standard letter-codes for reading arguments
                                in various ways.
+ * Non-string Interactive::  Non-string equivalents of the letter-codes.
  * Interactive Examples::    Examples of how to read interactive arguments.
  
  Input Events




Index: commands.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/doc/lispref/commands.texi,v
retrieving revision 1.18
diff -c -r1.18 commands.texi
*** commands.texi	4 Apr 2009 22:34:23 -0000	1.18
--- commands.texi	13 Apr 2009 19:07:23 -0000
***************
*** 113,142 ****
  the reading of arguments for an interactive call.
  
  @menu
! * Using Interactive::     General rules for @code{interactive}.
! * Interactive Codes::     The standard letter-codes for reading arguments
!                              in various ways.
! * Interactive Examples::  Examples of how to read interactive arguments.
  @end menu
  
  @node Using Interactive
  @subsection Using @code{interactive}
  @cindex arguments, interactive entry
  
!   This section describes how to write the @code{interactive} form that
! makes a Lisp function an interactively-callable command, and how to
! examine a command's @code{interactive} form.
  
  @defspec interactive arg-descriptor
  This special form declares that a function is a command, and that it
  may therefore be called interactively (via @kbd{M-x} or by entering a
  key sequence bound to it).  The argument @var{arg-descriptor} declares
  how to compute the arguments to the command when the command is called
! interactively.
  
! A command may be called from Lisp programs like any other function, but
! then the caller supplies the arguments and @var{arg-descriptor} has no
! effect.
  
  @cindex @code{interactive-form}, function property
  The @code{interactive} form must be located at top-level in the
--- 113,144 ----
  the reading of arguments for an interactive call.
  
  @menu
! * Using Interactive::           General rules for @code{interactive}.
! * Interactive Codes::           The standard letter-codes for reading arguments
!                                 in various ways.
! * Non-string Interactive::      Non-string equivalents of the letter-codes.
! * Interactive Examples::        Examples of how to read interactive arguments.
  @end menu
  
  @node Using Interactive
  @subsection Using @code{interactive}
  @cindex arguments, interactive entry
  
!   This section describes how to write and examine the @dfn{interactive
! form}.  This form makes a Lisp function an interactively-callable
! command, and tells the interpreter how to call it.
  
  @defspec interactive arg-descriptor
  This special form declares that a function is a command, and that it
  may therefore be called interactively (via @kbd{M-x} or by entering a
  key sequence bound to it).  The argument @var{arg-descriptor} declares
  how to compute the arguments to the command when the command is called
! interactively, and sometimes directs the interpreter to perform
! auxiliary actions such as checking the buffer is writable.
  
! A command may be called from Lisp programs like any other function,
! but then the caller supplies the arguments and @var{arg-descriptor} is
! ignored.
  
  @cindex @code{interactive-form}, function property
  The @code{interactive} form must be located at top-level in the
***************
*** 166,187 ****
  or more arguments.
  
  @item
! It may be a string; its contents are a sequence of elements separated
! by newlines, one for each parameter@footnote{Some elements actually
! supply two parameters.}.  Each element consists of a code character
! (@pxref{ Interactive Codes}) optionally followed by a prompt (which
! some code characters use and some ignore).  Here is an example:
  
  @smallexample
! (interactive "P\nbFrobnicate buffer: ")
  @end smallexample
  
  @noindent
! The code letter @samp{P} sets the command's first argument to the raw
! command prefix (@pxref{Prefix Command Arguments}).  @samp{bFrobnicate
! buffer: } prompts the user with @samp{Frobnicate buffer: } to enter
! the name of an existing buffer, which becomes the second and final
! argument.
  
  @c Emacs 19 feature
  The prompt string can use @samp{%} to include previous argument values
--- 168,213 ----
  or more arguments.
  
  @item
! It may be a string; the string's contents are:
! 
! @itemize @minus
! @item
! Zero or more of the ``special'' code characters @samp{*}, @samp{@@},
! @samp{^}, which direct Emacs to perform auxiliary functions
! (@pxref{Interactive Codes}) before getting the command's arguments.
! They are processed in the order they appear.  They are directly
! followed by
! @item
! a sequence of elements separated by newlines, one for each
! argument@footnote{Some elements actually supply two arguments.}.
! Each element consists of a code character (@pxref{ Interactive Codes})
! optionally followed by a prompt (which some code characters use and
! some ignore).  The prompt typically ends with @samp{: }.
! @end itemize
! 
! Here is an example:
  
  @smallexample
! (interactive "*P\nbFrobnicate buffer: ")
  @end smallexample
  
  @noindent
! The @samp{*} checks that the buffer is writable, signaling an error if
! it's read-only.  The code letter @samp{P} sets the command's first
! argument to the raw command prefix (@pxref{Prefix Command Arguments}).
! @samp{bFrobnicate buffer: } prompts the user with @samp{Frobnicate
! buffer: } to enter the name of an existing buffer, which becomes the
! second and final argument.
! 
! There are more examples in @xref{Interactive Examples}.
! 
! The string form of the argument is used more often than a general lisp
! expression, since it's more convenient.  However, sometimes you'll
! have to write a non-string lisp form (see below) since the string form
! can't always do what you need.  For your convenience, a non-string
! equivalent of each code character is given in @ref{Non-string
! Interactive}.
! 
  
  @c Emacs 19 feature
  The prompt string can use @samp{%} to include previous argument values
***************
*** 196,229 ****
  @end group
  @end smallexample
  
- @cindex @samp{*} in @code{interactive}
- @cindex read-only buffers in interactive
- If @samp{*} appears at the beginning of the string, then an error is
- signaled if the buffer is read-only.
- 
- @cindex @samp{@@} in @code{interactive}
- @c Emacs 19 feature
- If @samp{@@} appears at the beginning of the string, and if the key
- sequence used to invoke the command includes any mouse events, then
- the window associated with the first of those events is selected
- before the command is run.
- 
- @cindex @samp{^} in @code{interactive}
- @cindex shift-selection, and @code{interactive} spec
- If @samp{^} appears at the beginning of the string, and if the command
- was invoked through @dfn{shift-translation}, set the mark and activate
- the region temporarily, or extend an already active region, before the
- command is run.  If the command was invoked without shift-translation,
- and the region is temporarily active, deactivate the region before the
- command is run.  Shift-translation is controlled on the user level by
- @code{shift-select-mode}; see @ref{Shift Selection,,, emacs, The GNU
- Emacs Manual}.
- 
- You can use @samp{*}, @samp{@@}, and @code{^} together; the order does
- not matter.  Actual reading of arguments is controlled by the rest of
- the prompt string (starting with the first character that is not
- @samp{*}, @samp{@@}, or @samp{^}).
- 
  @item
  It may be a Lisp expression that is not a string; then it should be a
  form that is evaluated to get a list of arguments to pass to the
--- 222,227 ----
***************
*** 290,297 ****
  @cindex codes, interactive, description of
  @cindex characters for interactive codes
  
!   The code character descriptions below contain a number of key words,
! defined here as follows:
  
  @table @b
  @item Completion
--- 288,299 ----
  @cindex codes, interactive, description of
  @cindex characters for interactive codes
  
!   This page describes the @dfn{code characters}, the letters and
! punctuation marks contained in the string form of the argument to
! @code{interactive} (@pxref{Using Interactive}).
! 
!   The descriptions below contain a number of key words, defined here
! as follows:
  
  @table @b
  @item Completion
***************
*** 329,350 ****
  @end table
  
  @cindex reading interactive arguments
!   Here are the code character descriptions for use with @code{interactive}:
  
  @table @samp
  @item *
  Signal an error if the current buffer is read-only.  Special.
  
  @item @@
! Select the window mentioned in the first mouse event in the key
  sequence that invoked this command.  Special.
  
  @item ^
! If the command was invoked through shift-translation, set the mark and
! activate the region temporarily, or extend an already active region,
! before the command is run.  If the command was invoked without
! shift-translation, and the region is temporarily active, deactivate
! the region before the command is run.  Special.
  
  @item a
  A function name (i.e., a symbol satisfying @code{fboundp}).  Existing,
--- 331,368 ----
  @end table
  
  @cindex reading interactive arguments
!   Here are the code character descriptions for use with
! @code{interactive}.  Non-string equivalents of these codes can be
! found in @ref{Non-string Interactive}.
  
  @table @samp
+ @cindex @samp{*} in @code{interactive}
+ @cindex read-only buffers in interactive
  @item *
  Signal an error if the current buffer is read-only.  Special.
  
+ @cindex @samp{@@} in @code{interactive}
  @item @@
! If the key sequence that invokes the command contains a mouse event,
! select the window mentioned in the first mouse event in the key
  sequence that invoked this command.  Special.
  
+ @cindex @samp{^} in @code{interactive}
+ @cindex shift-selection, and @code{interactive} spec
  @item ^
! This is intended for movement commands.  If the command was invoked
! through shift-translation, set the mark and activate the region
! temporarily, or extend an already active region, before the command is
! run.  If the command was invoked without shift-translation, and the
! region is temporarily active, deactivate the region before the command
! is run.  Shift-translation is controlled on the user level by
! @code{shift-select-mode}; @xref{Shift Selection,,, emacs, The GNU
! Emacs Manual}. @footnote{Note that the code character @samp{^} was
! introduced in Emacs 23 and will cause an error if used in earlier
! Emacs versions.  If you want to use @samp{^} yet your command needs to
! run in an earlier version of Emacs, you should write the interactive
! spec as a non-string form instead.  (@pxref{Non-string Interactive})}
! Special.
  
  @item a
  A function name (i.e., a symbol satisfying @code{fboundp}).  Existing,
***************
*** 356,363 ****
  Prompt.
  
  @item B
! A buffer name.  The buffer need not exist.  By default, uses the name of
! a recently used buffer other than the current buffer.  Completion,
  Default, Prompt.
  
  @item c
--- 374,381 ----
  Prompt.
  
  @item B
! A buffer name.  The buffer need not exist.  By default, uses the name
! of a recently used buffer other than the current buffer.  Completion,
  Default, Prompt.
  
  @item c
***************
*** 504,509 ****
--- 522,771 ----
  argument value.  Completion, Existing, Prompt.
  @end table
  
+ @node Non-string Interactive
+ @comment  node-name,  next,  previous,  up
+ @subsection Non-string Equivalents of Interactive Code Characters
+ 
+ This page sketches non-string equivalents for each of the code
+ characters used in the string version of the interactive form.  These
+ should help you when you when you need to build the functionality of
+ the code characters into a non-string interactive form.  The semantics
+ of a non-string interactive form is defined in @ref{Using Interactive}
+ and the individual code characters are defined in @ref{Interactive
+ Codes}.
+ 
+ @table @asis
+ @item @samp{*} - check buffer is writable
+ @lisp
+ (interactive (progn (barf-if-buffer-readonly) nil))
+ @c There's funny stuff in callint.c; if the interactive string
+ @c consists of one other element besides '*', and that element isn't
+ @c 'p', 'P', or 'r', it is processed first before calling `barf-if-..'.
+ @c I don't know why this is so.  (ACM, 2009-04-10).
+ @end lisp
+ 
+ @item @samp{@@} - Select window of mouse event
+ @lisp
+ (interactive
+  (let ((events (this-command-keys-vector))
+        e w
+        (i 0))
+    (while (and (< i (length events))
+                (not (consp (setq e (aref events i)))))
+      (setq i (1+ i)))
+    (when (consp e)
+      (setq w (car (cadr e)))
+      (if (windowp w)
+          (if (and (window-minibuffer-p w)
+                   (> (minibuffer-depth) 0))
+              (error "Attempt to select silly inactive minibuffer window")))
+      (run-hooks mouse-leave-buffer-hook)
+      (select-window w))
+    nil))
+ @end lisp
+ Note that this form only works when the @var{keys} parameter to
+ @code{call-interactively} is @code{nil} (which it almost always is).
+ 
+ @item @samp{^} - shift-translation
+ @lisp
+ (interactive
+  (progn (if (fboundp 'handle-shift-selection)
+             (handle-shift-selection))
+         nil))
+ @end lisp
+ 
+ @item @samp{a} - function name
+ @lisp
+ (interactive (list (completing-read "Function: " obarray 'fboundp t)))
+ @end lisp
+ 
+ @item @samp{b} - existing buffer
+ @lisp
+ (interactive (list (read-buffer "Buffer: " (current-buffer) t)))
+ @end lisp
+ 
+ @item @samp{B} - buffer
+ @lisp
+ (interactive (list (read-buffer "Buffer: " (other-buffer))))
+ @end lisp
+ 
+ @item @samp{c} - character
+ @lisp
+ (interactive
+  (let ((prompt "Char: "))
+    (put-text-property 0 (length prompt) 'face 'minibuffer-prompt prompt)
+    (list (read-char prompt))))
+ @end lisp
+ 
+ @item @samp{C} - command
+ @lisp
+ (interactive (list (completing-read "Command: " obarray 'commandp t)))
+ @end lisp
+ 
+ @item @samp{d} - point
+ @lisp
+ (interactive (list (point)))
+ @end lisp
+ 
+ @item @samp{D} - existing directory
+ @lisp
+ (interactive
+  (list (read-file-name "Directory: "
+                        nil default-directory t nil 'file-directory-p)))
+ @end lisp
+ 
+ @item @samp{e} - mouse event
+ @lisp
+ (interactive
+  (let* ((events (this-command-keys-vector))
+         e
+         (i 0))
+    (while (and (< i (length events))
+                (not (consp (setq e (aref events i)))))
+      (setq i (1+ i)))
+    (and (consp e) (list e))))
+ @end lisp
+ Note that this form only works when the @var{keys} parameter to
+ @code{call-interactively} is @code{nil} (which it almost always is).
+ 
+ @item @samp{f} - existing file
+ @lisp
+ (interactive (list (read-file-name "File name: " nil nil t)))
+ @end lisp
+ 
+ @item @samp{F} - file
+ @lisp
+ (interactive (list (read-file-name "File name: ")))
+ @end lisp
+ 
+ @item @samp{G} - file or directory
+ @lisp
+ (interactive (list (read-file-name "F or d name: " nil nil nil "")))
+ @end lisp
+ 
+ @item @samp{i} - nil
+ @lisp
+ (interactive '(nil))
+ @end lisp
+ 
+ @item @samp{k} - key sequence (with case conversion)
+ @lisp
+ (interactive
+  (let ((prompt "Key binding: ")
+        (ks) last-event)
+    (put-text-property 0 (length prompt) 'face 'minibuffer-prompt prompt)
+    (setq ks (read-key-sequence prompt)
+          last-event (aref ks (1- (length ks))))
+    (if (consp last-event) (setq last-event (car last-event)))
+    (setq my-up-event
+          (and (symbolp last-event)
+               (memq 'down (get last-event 'event-symbol-elements))
+               (vector (read-event))))
+    (list ks)))
+ @end lisp
+ Note how @code{my-up-event} gets set to the mouse up event, if any.
+ You can use this for the @samp{U} equivalent (see below).
+ 
+ @item @samp{K} - key sequence (no case conversion)
+ @lisp
+ (interactive
+  (let ((prompt "Key binding: ")
+        (ks) last-event)
+    (put-text-property 0 (length prompt) 'face 'minibuffer-prompt prompt)
+    (setq ks (read-key-sequence prompt nil t)
+          last-event (aref ks (1- (length ks))))
+    (if (consp last-event) (setq last-event (car last-event)))
+    (setq my-up-event
+          (and (symbolp last-event)
+               (memq 'down (get last-event 'event-symbol-elements))
+               (vector (read-event))))
+    (list ks)))
+ @end lisp
+ Note how @code{my-up-event} gets set to the mouse up event, if any.
+ You can use this for the @samp{U} equivalent (see below).
+ 
+ @item @samp{m} - mark
+ @lisp
+ (interactive (list (mark)))
+ @end lisp
+ 
+ @item @samp{M} - text (with current input method)
+ @lisp
+ (interactive (list (read-string "Text: " nil nil nil t)))
+ @end lisp
+ 
+ @item @samp{n} - number
+ @lisp
+ (interactive (list (read-number "Number: ")))
+ @end lisp
+ 
+ @item @samp{N} - numeric prefix or read number
+ @lisp
+ (interactive
+  (list (if current-prefix-arg
+            (prefix-numeric-value current-prefix-arg)
+          (read-number "Number: "))))
+ @end lisp
+ 
+ @item @samp{p} - numeric prefix
+ @lisp
+ (interactive (list (prefix-numeric-value current-prefix-arg)))
+ @end lisp
+ 
+ @item @samp{P} - raw prefix
+ @lisp
+ (interactive (list current-prefix-arg))
+ @end lisp
+ 
+ @item @samp{r} - region
+ @lisp
+ (interactive (list (region-beginning) (region-end)))
+ @end lisp
+ 
+ @item @samp{s} - text (without input method)
+ @lisp
+ (interactive (list (read-string "Text: " nil nil nil t)))
+ @end lisp
+ 
+ @item @samp{S} - symbol
+ @lisp
+ (interactive (list (intern (read-string "Symbol: "))))
+ @end lisp
+ 
+ @item @samp{U} - mouse up event
+ @lisp
+ (interactive (list my-up-event))
+ @end lisp
+ @code{my-up-event} is set by the lisp for @samp{k} or @samp{K}.  You
+ should declare and maintain this variable in your own code.
+ 
+ @item @samp{v} - user option
+ @lisp
+ (interactive (list (read-variable "Option: ")))
+ @end lisp
+ 
+ @item @samp{x} - lisp expression
+ @lisp
+ (interactive (list (read-minibuffer "Lisp expression: ")))
+ @end lisp
+ 
+ @item @samp{X} - lisp expression, evaluated
+ @lisp
+ (interactive (list (eval-minibuffer "Lisp expression: ")))
+ @end lisp
+ 
+ @item @samp{z} - coding system (or nil)
+ @lisp
+ (interactive (list (read-coding-system "Coding system: ")))
+ @end lisp
+ 
+ @item @samp{Z} - with prefix arg, coding system else nil
+ @lisp
+ (interactive (list (and current-prefix-arg
+                         (read-non-nil-coding-system "Coding system: "))))
+ @end lisp
+ @end table
+ 
  @node Interactive Examples
  @comment  node-name,  next,  previous,  up
  @subsection Examples of Using @code{interactive}
***************
*** 530,537 ****
  @end group
  
  @group
! (defun foo3 (n)             ; @r{@code{foo3} takes one argument,}
!     (interactive "nCount:") ;   @r{which is read with the Minibuffer.}
      (forward-word (* 2 n)))
       @result{} foo3
  @end group
--- 792,799 ----
  @end group
  
  @group
! (defun foo3 (n)              ; @r{@code{foo3} takes one argument,}
!     (interactive "nCount: ") ;   @r{which is read with the Minibuffer.}
      (forward-word (* 2 n)))
       @result{} foo3
  @end group
***************
*** 541,547 ****
    "Select three existing buffers.
  Put them into three windows, selecting the last one."
  @end group
!     (interactive "bBuffer1:\nbBuffer2:\nbBuffer3:")
      (delete-other-windows)
      (split-window (selected-window) 8)
      (switch-to-buffer b1)
--- 803,809 ----
    "Select three existing buffers.
  Put them into three windows, selecting the last one."
  @end group
!     (interactive "bBuffer1: \nbBuffer2: \nbBuffer3: ")
      (delete-other-windows)
      (split-window (selected-window) 8)
      (switch-to-buffer b1)



>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat. (Patch)

[Eli Zaretskii]

> Date: Mon, 13 Apr 2009 19:32:55 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
> 
> OK, here's the patch.  In the end, I put all these lisp forms into a new
> page "Non-string Interactive" because it seemed better balanced.

Thanks.

> I think that the order of "*" and "@" in (interactive "@*") matters.
> Well, it would matter if there were any commands which use them both;
> there aren't in Emacs.
> 
> It's a fairly hefty patch, so any review/criticism would be welcome.

My $0.02 are below:

> 	(Non-string Interactive): New page giving non-string equivalents
                                  ^^^^^^^^
"New node" or "New section".

>   @menu
> ! * Using Interactive::           General rules for @code{interactive}.
> ! * Interactive Codes::           The standard letter-codes for reading arguments
> !                                 in various ways.
> ! * Non-string Interactive::      Non-string equivalents of the letter-codes.
> ! * Interactive Examples::        Examples of how to read interactive arguments.
>   @end menu

Why did you add whitespace between the menu items and their
descriptions? now the lines are too long, IMO.  Suggest to reduce the
whitespace back.

> ! @item
> ! Zero or more of the ``special'' code characters @samp{*}, @samp{@@},
> ! @samp{^}, which direct Emacs to perform auxiliary functions
> ! (@pxref{Interactive Codes}) before getting the command's arguments.
> ! They are processed in the order they appear.  They are directly
> ! followed by
> ! @item

This "they are directly followed by" trick is not a very good idea,
IMO.  In particularly, it doesn't look like correct English.  You
already say above "zero or more", so it's quite clear the others
directly follow.

>  The prompt typically ends with @samp{: }.

Suggest to rephrase as

   The prompt typically ends with @samp{:} followed by a space.

It is generally not a good idea to have whitespace inside @samp.

> ! The @samp{*} checks that the buffer is writable, signaling an error if

"buffer is writable" sounds strange.  How about

  The @samp{*} checks that the buffer is read-only, and signals an
  error if so.

or simply

  The @samp{*} signals an error if the buffer is read-only.

> ! There are more examples in @xref{Interactive Examples}.

@xref generates "See ...", with a capital S, in the printed version,
so it is unsuitable for the middle of a sentence, both grammatically
and syntactically.  Use @ref instead.

> ! The string form of the argument is used more often than a general lisp
> ! expression, since it's more convenient.  However, sometimes you'll
> ! have to write a non-string lisp form (see below) since the string form

"Lisp" should be capitalized (two counts in the above paragraph).

> + @cindex @samp{*} in @code{interactive}
> + @cindex read-only buffers in interactive

Why "interactive" is not in @code in the second index entry?

> ! @code{shift-select-mode}; @xref{Shift Selection,,, emacs, The GNU
> ! Emacs Manual}. @footnote{Note that the code character @samp{^} was

@footnote should come before the period that ends the previous
sentence.  It is converted to a superscript n, so having it after the
period looks incorrect.

> ! Emacs versions.  If you want to use @samp{^} yet your command needs to
> ! run in an earlier version of Emacs, you should write the interactive
> ! spec as a non-string form instead.  (@pxref{Non-string Interactive})}

@pxref is not useful inside parens that stand by themselves, outside
of any sentence.  Just use @xref here (without the parens).

> + @node Non-string Interactive
> + @comment  node-name,  next,  previous,  up
> + @subsection Non-string Equivalents of Interactive Code Characters

It is usually a good idea to have one or more @cindex entries at the
beginning of each section that gives the main subject of the section.
Imagine yourself a year from now looking for this stuff, and ask
yourself what phrases you'd think about -- these are the phrases you
need to put in the @cindex entry for the section.  The name of the
node, or some trivial transformation of it, is usually the first
choice.

> + should help you when you when you need to build the functionality of
                    ^^^^^^^^^^^^^^^^^
"when you" twice.

> + the code characters into a non-string interactive form.  The semantics

This rationale for the functionality doesn't really explain it.  In a
nutshell, it says "You will want the non-string equivalents when you
need the non-string interactive form."  That's a tautology.  Can you
come up with a better rationale?

> + of a non-string interactive form is defined in @ref{Using Interactive}

You need a comma after the "@ref{Using Interactive}"; makeinfo will
complain if you don't have it.

> +              (error "Attempt to select silly inactive minibuffer window")))

This line is too long, and will overflow the right margin in a printed
manual.  Please break it into two lines.

> +      (run-hooks mouse-leave-buffer-hook)
> +      (select-window w))
> +    nil))
> + @end lisp
> + Note that this form only works when the @var{keys} parameter to
> + @code{call-interactively} is @code{nil} (which it almost always is).

Since there's no call to call-interactively anywhere in sight, a
cross-reference to the node where it's described would be a good idea,
in case the reader forgot what is that KEYS argument.

> + 
> + @item @samp{^} - shift-translation
> + @lisp
> + (interactive
> +  (progn (if (fboundp 'handle-shift-selection)
> +             (handle-shift-selection))
> +         nil))
> + @end lisp
> + 
> + @item @samp{a} - function name
> + @lisp
> + (interactive (list (completing-read "Function: " obarray 'fboundp t)))
> + @end lisp
> + 
> + @item @samp{b} - existing buffer
> + @lisp
> + (interactive (list (read-buffer "Buffer: " (current-buffer) t)))
> + @end lisp

Do we _really_ need an example for _each_one_ of the codes?  Some of
them are quite trivial, why put them in the manual?  A couple of
trivial examples and a few more non-trivial ones, that's all that's
needed to get the idea.

> +    (put-text-property 0 (length prompt) 'face 'minibuffer-prompt prompt)

Line too long.

> + (interactive (list (completing-read "Command: " obarray 'commandp t)))

Ditto.

> +                        nil default-directory t nil 'file-directory-p)))

Ditto.

> +    (put-text-property 0 (length prompt) 'face 'minibuffer-prompt prompt)

Ditto.

> +    (put-text-property 0 (length prompt) 'face 'minibuffer-prompt prompt)

Ditto.

> +                         (read-non-nil-coding-system "Coding system: "))))

Ditto.

Re: Interactive hat. (Patch)

[Miles Bader]

> + * Non-string Interactive::  Non-string equivalents of the letter-codes.

The phrase "non-string interactive" sounds kind of awkward to
me... maybe something like "evaluated interactive forms" or "code
interactive forms" might be better...

-Miles

-- 
You can hack anything you want, with TECO and DDT.

Re: Interactive hat. (Patch)

[Alan Mackenzie]

Hi, Eli!

That was some impressive proof-reading.  Thank you very much indeed!

I've corrected most of the mistakes you pointed out, and incorporated
most of your suggestions which weren't about mistakes.  What remains is:

On Mon, Apr 13, 2009 at 11:47:03PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 13 Apr 2009 19:32:55 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org

> My $0.02 are below:

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

> >   @menu
> > ! * Using Interactive::           General rules for @code{interactive}.
> > ! * Interactive Codes::           The standard letter-codes for reading arguments
> > !                                 in various ways.
> > ! * Non-string Interactive::      Non-string equivalents of the letter-codes.
> > ! * Interactive Examples::        Examples of how to read interactive arguments.
> >   @end menu

> Why did you add whitespace between the menu items and their
> descriptions? now the lines are too long, IMO.  Suggest to reduce the
> whitespace back.

I didn't add the whitespace, as such.  C-c C-u C-m `texinfo-make-menu'
did it for me, so I wasn't fully aware of it.  Anyhow, I've taken all but
one of the spaces out, to leave the minimum gap (1 space) between
"Interactive::" and "Non-string"

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

> > ! The @samp{*} checks that the buffer is writable, signaling an error if

> "buffer is writable" sounds strange.  How about

>   The @samp{*} checks that the buffer is read-only, and signals an
>   error if so.

> or simply

>   The @samp{*} signals an error if the buffer is read-only.

It seems a bit negative.  "Writable" seems more positive than "not
read-only".  I'll think a bit more about this.

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

> > ! @code{shift-select-mode}; @xref{Shift Selection,,, emacs, The GNU
> > ! Emacs Manual}. @footnote{Note that the code character @samp{^} was

> @footnote should come before the period that ends the previous
> sentence.  It is converted to a superscript n, so having it after the
> period looks incorrect.

I got some strange interactions between @footnote and the @xref near the
end of the paragraph.  makeinfo left ".)" on a line of its own at the
end, even though there was plenty of space on the line before.

In the end, I moved the footnote to near the start of the pargraph.  I'm
(still) getting trouble from makeinfo 4.7, though.  It generates this for
the end of that paragraph:

     Shift-translation is controlled on the user level by
     `shift-select-mode'; see Shift Selection(emacs)
     .  Special.

, with that oddly placed full stop.  The corresponding bit of .texi is:

Shift-translation is controlled on the user level by
@code{shift-select-mode}; @xref{Shift Selection,,, emacs, The GNU
Emacs Manual}.  Special.

Have you any idea what's going wrong?

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

> > + @node Non-string Interactive
> > + @comment  node-name,  next,  previous,  up
> > + @subsection Non-string Equivalents of Interactive Code Characters

> It is usually a good idea to have one or more @cindex entries at the
> beginning of each section that gives the main subject of the section.
> Imagine yourself a year from now looking for this stuff, and ask
> yourself what phrases you'd think about -- these are the phrases you
> need to put in the @cindex entry for the section.  The name of the
> node, or some trivial transformation of it, is usually the first
> choice.

Hmm.  Difficult!  My first attempt was more like a sentence and was far
too long.  The best I can manage right now is:

    @cindex Non-string interactive code

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

> > + the code characters into a non-string interactive form.  The semantics

> This rationale for the functionality doesn't really explain it.  In a
> nutshell, it says "You will want the non-string equivalents when you
> need the non-string interactive form."  That's a tautology.  Can you
> come up with a better rationale?

Very good point!  How about something like: "These should help you when
you need to combine the effect of a standard code character with lisp
code which is specific to your command."?

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

> > +              (error "Attempt to select silly inactive minibuffer window")))

> This line is too long, and will overflow the right margin in a printed
> manual.  Please break it into two lines.

The "silly" shouldn't have escaped from my test file :-).  I'll get all
the line lengths right before the next version of the patch.

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

> > + 
> > + @item @samp{^} - shift-translation
> > + @lisp
> > + (interactive
> > +  (progn (if (fboundp 'handle-shift-selection)
> > +             (handle-shift-selection))
> > +         nil))
> > + @end lisp
> > + 
> > + @item @samp{a} - function name
> > + @lisp
> > + (interactive (list (completing-read "Function: " obarray 'fboundp t)))
> > + @end lisp
> > + 
> > + @item @samp{b} - existing buffer
> > + @lisp
> > + (interactive (list (read-buffer "Buffer: " (current-buffer) t)))
> > + @end lisp

> Do we _really_ need an example for _each_one_ of the codes?  Some of
> them are quite trivial, why put them in the manual?  A couple of
> trivial examples and a few more non-trivial ones, that's all that's
> needed to get the idea.

I've been mulling that over.  I think each code should be mentioned (the
whole idea is to save manual scanning effort for lazy elisp maintainers),
but perhaps not so bloatedly as I've done.  How about compacting the easy
ones into a compact list, and leaving the more difficult ones as they
are, something like:

"Many of the code characters are equivalent to a single Lisp function.
These are:

    `*` - `barf-if-readonly'
    `d' - `point'
    ....
    `z' - `read-coding-system'

The other code characters need more involved coding to emulate, for
example:

`K' - key sequence (no case conversion)
          (interactive
           (let ((prompt "Key binding: ")
                 (ks) last-event)
....

"?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat. (Patch)

[Alan Mackenzie]

Hi, Miles!

On Tue, Apr 14, 2009 at 07:50:01AM +0900, Miles Bader wrote:
> > + * Non-string Interactive::  Non-string equivalents of the letter-codes.

> The phrase "non-string interactive" sounds kind of awkward to
> me... maybe something like "evaluated interactive forms" or "code
> interactive forms" might be better...

But also more confusing.  "non-string" is at least accurate.  There's no
compelling reason a non-string form MUST be evaluated.  It could
conceivably be a constant list which has been evaluated at compile time,
for example.  OK, maybe that's too implausible.

Maybe a compromise would be better, leaving the node name, but amending
the comment.  Say:

* Non-string Interactive::  Explicitly evaluated equivalents of the letter-codes.

, or something like that.

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat. (Patch)

[Eli Zaretskii]

> Date: Tue, 14 Apr 2009 20:15:38 +0000
> Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> That was some impressive proof-reading.  Thank you very much indeed!

Thank _you_ for working on this in the first place.

> > Why did you add whitespace between the menu items and their
> > descriptions? now the lines are too long, IMO.  Suggest to reduce the
> > whitespace back.
> 
> I didn't add the whitespace, as such.  C-c C-u C-m `texinfo-make-menu'
> did it for me, so I wasn't fully aware of it.  Anyhow, I've taken all but
> one of the spaces out, to leave the minimum gap (1 space) between
> "Interactive::" and "Non-string"

That's good.  Yes, `texinfo-make-menu' is known for adding gratuitous
whitespace.

> > > ! The @samp{*} checks that the buffer is writable, signaling an error if
> 
> > "buffer is writable" sounds strange.  How about
> 
> >   The @samp{*} checks that the buffer is read-only, and signals an
> >   error if so.
> 
> > or simply
> 
> >   The @samp{*} signals an error if the buffer is read-only.
> 
> It seems a bit negative.  "Writable" seems more positive than "not
> read-only".  I'll think a bit more about this.

There was no "not" in the text I suggested.

> In the end, I moved the footnote to near the start of the pargraph.  I'm
> (still) getting trouble from makeinfo 4.7, though.  It generates this for
> the end of that paragraph:
> 
>      Shift-translation is controlled on the user level by
>      `shift-select-mode'; see Shift Selection(emacs)
>      .  Special.
> 
> , with that oddly placed full stop.  The corresponding bit of .texi is:
> 
> Shift-translation is controlled on the user level by
> @code{shift-select-mode}; @xref{Shift Selection,,, emacs, The GNU
> Emacs Manual}.  Special.
> 
> Have you any idea what's going wrong?

Nothing's wrong; you are looking at the result of info.el's attempt to
beautify the Info cross-reference syntax, and failing spectacularly
when it spans more than a single line.  Please visit the produced Info
file literally, and you will see that the text produced by makeinfo is
perfectly okay.

> > It is usually a good idea to have one or more @cindex entries at the
> > beginning of each section that gives the main subject of the section.
> > Imagine yourself a year from now looking for this stuff, and ask
> > yourself what phrases you'd think about -- these are the phrases you
> > need to put in the @cindex entry for the section.  The name of the
> > node, or some trivial transformation of it, is usually the first
> > choice.
> 
> Hmm.  Difficult!  My first attempt was more like a sentence and was far
> too long.  The best I can manage right now is:
> 
>     @cindex Non-string interactive code

Well, this is related to Miles's comments.  Maybe if we find a better
term for this, the index entry could use that.

> > This rationale for the functionality doesn't really explain it.  In a
> > nutshell, it says "You will want the non-string equivalents when you
> > need the non-string interactive form."  That's a tautology.  Can you
> > come up with a better rationale?
> 
> Very good point!  How about something like: "These should help you when
> you need to combine the effect of a standard code character with lisp
> code which is specific to your command."?

Wasn't your motivation primarily portability to versions of Emacs that
don't support some of the newer characters?  If so, why not say that?

> "Many of the code characters are equivalent to a single Lisp function.
> These are:
> 
>     `*` - `barf-if-readonly'
>     `d' - `point'
>     ....
>     `z' - `read-coding-system'
> 
> The other code characters need more involved coding to emulate, for
> example:
> 
> `K' - key sequence (no case conversion)
>           (interactive
>            (let ((prompt "Key binding: ")
>                  (ks) last-event)
> ....
> 
> "?

That's a very good idea, IMO.

Re: Interactive hat. (Patch)

[Eli Zaretskii]

> Date: Tue, 14 Apr 2009 20:22:53 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> On Tue, Apr 14, 2009 at 07:50:01AM +0900, Miles Bader wrote:
> > > + * Non-string Interactive::  Non-string equivalents of the letter-codes.
> 
> > The phrase "non-string interactive" sounds kind of awkward to
> > me... maybe something like "evaluated interactive forms" or "code
> > interactive forms" might be better...
> 
> But also more confusing.  "non-string" is at least accurate.

How about "Lisp interactive"?  You are, after all, describing Lisp
equivalents of the letter codes.

Re: Interactive hat. (Patch)

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > How about "Lisp interactive"?  You are, after all, describing Lisp
 > equivalents of the letter codes.

Or "Computed Interactive".

Re: Interactive hat. (Patch V2)

[Eli Zaretskii]

> Date: Thu, 23 Apr 2009 20:50:30 +0000
> Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > ! The @samp{*} checks that the buffer is writable, signaling an error if
> 
> > "buffer is writable" sounds strange.  How about
> 
> >   The @samp{*} checks that the buffer is read-only, and signals an
> >   error if so.
> 
> > or simply
> 
> >   The @samp{*} signals an error if the buffer is read-only.
> 
> I cut the sentence down to "The `*' checks that the buffer is writable.".

But we don't use ``writable buffer'' anywhere else.  A file can be
writable, but a buffer?

Why didn't you like one of my suggestions, or some variation thereof?

> ! @itemize @minus
> ! @item
> ! Zero or more of the ``special'' code characters @samp{*}, @samp{@@},
> ! @samp{^}, which direct Emacs to perform auxiliary functions
> ! (@pxref{Interactive Codes}) before getting the command's arguments.
> ! They are processed in the order they appear.
> ! @item
> ! a sequence of elements separated by newlines, one for each

The first @item's text is capitalized, but the second one's isn't.

> + @subsection Non-string Equivalents of Interactive Code Characters
> + @cindex Non-string interactive code

I suggest "@cindex non-string interactive spec".  Note that all index
entries begin with a lower-case letter, to avoid dependency on sort
order in the index, and also for uniformity.

> + @table @asis
> + @item @samp{*}: @code{(barf-if-buffer-readonly)}
> + @itemx @samp{d}: @code{(point)}
> + @itemx @samp{i}: @code{nil}
> + @itemx @samp{m}: @code{(mark)}
> + @itemx @samp{n}: @code{(read-number)}
> + @itemx @samp{P}: @code{current-prefix-arg}
> + @itemx @samp{r}: @code{(region-beginning)} and @code{(region-end)}
> + @itemx @samp{v}: @code{(read-variable)}
> + @itemx @samp{x}: @code{(read-minibuffer)}
> + @itemx @samp{X}: @code{(eval-minibuffer)}
> + @itemx @samp{z}: @code{(read-coding-system)}
> + @end table

That's an unusual use of @itemx.  Beware: it could do something you
didn't intend in some future version of Texinfo.  (All that just to
save a blank line?...)

> + @code{(read-file-name @var{prompt} nil default-directory t nil
> + 'file-directory-p)}

Doesn't the second line need indentation?

> + @verbatim
> + (interactive
> +  (let ((events (this-command-keys-vector))
> +        e w
> +        (i 0))
> +    (while (and (< i (length events))
> +                (not (consp (setq e (aref events i)))))
> +      (setq i (1+ i)))
> +    (when (consp e)
> +      (setq w (car (cadr e)))
> +      (if (windowp w)
> +          (if (and (window-minibuffer-p w)
> +                   (> (minibuffer-depth) 0))
> +              (error
> +               "Attempt to select inactive minibuffer window")))
> +      (run-hooks mouse-leave-buffer-hook)
> +      (select-window w))
> +    nil))
> + @end verbatim

This @verbatim is not enough, I think: the typeface used by this
example will be different from every other example in the manual,
right?  You need to force the same typeface as in @example, somehow.

Btw, why didn't @example fit the bill?

> + @item @samp{K} - key sequence (no case conversion)
> + @verbatim
> + (interactive
> +  (let ((prompt "Key binding: ")
> +        (ks) last-event)
> +    (put-text-property 0 (length prompt) 'face
> +                       'minibuffer-prompt prompt)
> +    (setq ks (read-key-sequence prompt nil t)
> +          last-event (aref ks (1- (length ks))))
> +    (if (consp last-event) (setq last-event (car last-event)))
> +    (setq my-up-event
> +          (and (symbolp last-event)
> +               (memq 'down
> +                     (get last-event 'event-symbol-elements))
> +               (vector (read-event))))
> +    (list ks)))
> + @end verbatim
> + Note how @code{my-up-event} gets set to the mouse up event, if any.
> + You can use this for the @samp{U} equivalent (see below).

?? Copy-paste mistake?  The "Note" seems to be copied verbatim from
the previous example.

Re: Interactive hat. (Patch V2)

[Alan Mackenzie]

Hello, Eli,

Thanks, once again, for the proof reading.  I'll be correcting the
mistakes you've pointed out.  But in the meantime, allow me the
indulgence of a rant:

On Fri, Apr 24, 2009 at 04:38:52PM +0300, Eli Zaretskii wrote:

> > + @table @asis
> > + @item @samp{*}: @code{(barf-if-buffer-readonly)}
> > + @itemx @samp{d}: @code{(point)}
> > + @itemx @samp{i}: @code{nil}
> > + @itemx @samp{m}: @code{(mark)}
> > + @itemx @samp{n}: @code{(read-number)}
> > + @itemx @samp{P}: @code{current-prefix-arg}
> > + @itemx @samp{r}: @code{(region-beginning)} and @code{(region-end)}
> > + @itemx @samp{v}: @code{(read-variable)}
> > + @itemx @samp{x}: @code{(read-minibuffer)}
> > + @itemx @samp{X}: @code{(eval-minibuffer)}
> > + @itemx @samp{z}: @code{(read-coding-system)}
> > + @end table

> That's an unusual use of @itemx.  Beware: it could do something you
> didn't intend in some future version of Texinfo.  

I don't think so; at least, not if makeinfo does what its manual says.
@itemx is defined to be identical to @item, except for not inserting a
blank line.  (See page "itemx" in the manual).

> (All that just to save a blank line?...)

Ten blank lines, actually.

[ .... ]

> > + @code{(read-file-name @var{prompt} nil default-directory t nil
> > + 'file-directory-p)}

> Doesn't the second line need indentation?

Yes, it does.  Thanks!

> > + @verbatim
> > + (interactive
> > +  (let ((events (this-command-keys-vector))
> > +        e w
> > +        (i 0))
> > +    (while (and (< i (length events))
> > +                (not (consp (setq e (aref events i)))))
> > +      (setq i (1+ i)))
> > +    (when (consp e)
> > +      (setq w (car (cadr e)))
> > +      (if (windowp w)
> > +          (if (and (window-minibuffer-p w)
> > +                   (> (minibuffer-depth) 0))
> > +              (error
> > +               "Attempt to select inactive minibuffer window")))
> > +      (run-hooks mouse-leave-buffer-hook)
> > +      (select-window w))
> > +    nil))
> > + @end verbatim

> This @verbatim is not enough, I think: the typeface used by this
> example will be different from every other example in the manual,
> right?  You need to force the same typeface as in @example, somehow.

> Btw, why didn't @example fit the bill?

Because @example inserts silly whitespace, of which there is already too
much.

makeinfo is a fascist program, one which seems to think that there is no
documention whatsoever that cannot be improved by inserting an infinite
number of blank lines (despite what the Texinfo manual says) or indenting
otherwise innocent example source code to an arbitrarily far right
column.

The manual's description of these topics is of "note to self" quality
rather than having the rigor one would expect of a GNU manual.  (What
hacker would interpret "the text is not indented" to mean "the text is
indented to column 10"?)

I think I've wasted more time trying to get a good, reasonably compact
layout on the page I've written than it took me to write the material,
and it's been almost as much fun as coding in Cobol.  I've now joined
that body of hackers who hold Texinfo to be unsuitable for writing
manuals in, though it's still much better than most of the competition.

Yes, I should really submit a proper bug report to bug-texinfo, but I can
see myself having to follow up with a set of patches, and I really,
really don't want to spend time on this - I just can't be bothered.  I
need to get out more.

Don't worry, I'll get over it.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat. (Patch V2)

[Eli Zaretskii]

> Date: Mon, 27 Apr 2009 11:46:20 +0000
> Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>   Karl Berry <karl@freefriends.org>
> From: Alan Mackenzie <acm@muc.de>
> 
> > That's an unusual use of @itemx.  Beware: it could do something you
> > didn't intend in some future version of Texinfo.  
> 
> I don't think so; at least, not if makeinfo does what its manual says.
> @itemx is defined to be identical to @item, except for not inserting a
> blank line.  (See page "itemx" in the manual).

That's not what I meant.  I meant that you in effect have here @item's
without the text after them.  A @table is not supposed to be like
that, so who knows what will the output be?  In particular, HTML and
XML outputs may assume there always be some text, and if not, fail to
properly close the markup.

> > This @verbatim is not enough, I think: the typeface used by this
> > example will be different from every other example in the manual,
> > right?  You need to force the same typeface as in @example, somehow.
> 
> > Btw, why didn't @example fit the bill?
> 
> Because @example inserts silly whitespace, of which there is already too
> much.

It indents to the current indent (e.g., if you are in a @table), and
then a couple more columns.  I never found that annoying, let alone
silly.

> I've now joined that body of hackers who hold Texinfo to be
> unsuitable for writing manuals in, though it's still much better
> than most of the competition.

It's like democracy: the worst possible regime, except for all the
others.

Seriously, though: I have been writing Texinfo manuals and documents
for at least 15 years now, and I find it very convenient and the
results very nice.  Quite a few people asked me how I manage to
produce such nice-looking documents in Word ;-)

> Don't worry, I'll get over it.

Yes, please do.

Re: Interactive hat. (Patch V2)

[Karl Berry]

    Because @example inserts silly whitespace, 

@exampleindent 0

Re: Interactive hat. (Patch V2)

[Miles Bader]

karl@freefriends.org (Karl Berry) writes:
>     Because @example inserts silly whitespace, 
>
> @exampleindent 0

Alan, please just use @example... even if you don't like the default
formatting (everybody has their own tastes after all), that's still no
reason for examples you write to be formatted differently than every
other example in the manual.  The examples in this case are not large
and do not have extremely long lines, and I can't see any obvious reason
for them to be considered exceptional.

-Miles

-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: Interactive hat. (Patch V2)

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Tue, 28 Apr 2009 10:12:52 +0900
> Cc: acm@muc.de, eliz@gnu.org, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
> 	lekktu@gmail.com
> 
> karl@freefriends.org (Karl Berry) writes:
> >     Because @example inserts silly whitespace, 
> >
> > @exampleindent 0
> 
> Alan, please just use @example...

Seconded.

Re: Interactive hat. (Patch V2)

[Alan Mackenzie]

On Mon, Apr 27, 2009 at 07:14:04PM -0500, Karl Berry wrote:
>     Because @example inserts silly whitespace, 

> @exampleindent 0

Thanks.  But is there any reasonable way of restoring the previous
value?  Something like

   (let ((exampleindent 0))
    .....
    )

, but in Texinfo?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat. (Patch V2)

[Alan Mackenzie]

Hi, Miles!

On Tue, Apr 28, 2009 at 10:12:52AM +0900, Miles Bader wrote:
> karl@freefriends.org (Karl Berry) writes:
> >     Because @example inserts silly whitespace, 

> > @exampleindent 0

> Alan, please just use @example... even if you don't like the default
> formatting (everybody has their own tastes after all), that's still no
> reason for examples you write to be formatted differently than every
> other example in the manual.  The examples in this case are not large
> and do not have extremely long lines, and I can't see any obvious
> reason for them to be considered exceptional.

They don't have extremely long lines, but if your desired max column is
74 and @example indents to C15, you've effectively got

    (setq fill-column 59)

, for which lines don't need to be very long to overflow.  Is there a
max column documented anywhere?

> -Miles

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat. (Patch V2)

[Alan Mackenzie]

Hi, Eli,

On Mon, Apr 27, 2009 at 09:39:48PM +0300, Eli Zaretskii wrote:
> > > That's an unusual use of @itemx.  Beware: it could do something you
> > > didn't intend in some future version of Texinfo.  

> > I don't think so; at least, not if makeinfo does what its manual
> > says.  @itemx is defined to be identical to @item, except for not
> > inserting a blank line.  (See page "itemx" in the manual).

> That's not what I meant.  I meant that you in effect have here @item's
> without the text after them.  A @table is not supposed to be like that,
> so who knows what will the output be?  In particular, HTML and XML
> outputs may assume there always be some text, and if not, fail to
> properly close the markup.

Surely it's not unusual (in any markup language) to have a blank cell in
a table.  I've generated HTML, and it's fine.  I've generated XML, and it
looks fine too, as much as XML ever looks fine (though I don't know
offhand if I've got a suitable viewing program for it).

> > > This @verbatim is not enough, I think: the typeface used by this
> > > example will be different from every other example in the manual,
> > > right?  You need to force the same typeface as in @example, somehow.

> > > Btw, why didn't @example fit the bill?

> > Because @example inserts silly whitespace, of which there is already
> > too much.

> It indents to the current indent (e.g., if you are in a @table), and
> then a couple more columns.  I never found that annoying, let alone
> silly.

Yet you have pointed out lines in my patch which have been too long.
Have you never written @example code yourself, where the enforced
indentation has caused lines to become "too long"?

Using @example instead of @verbatim takes yet another 5 columns away.
Anyhow, I've put @example in now (as requested by Miles and yourself),
and split some more lines up.  There are, however, one or two lines which
go over C74 which can't sensibly be split.

> > I've now joined that body of hackers who hold Texinfo to be
> > unsuitable for writing manuals in, though it's still much better
> > than most of the competition.

> It's like democracy: the worst possible regime, except for all the
> others.

:-)

> Seriously, though: I have been writing Texinfo manuals and documents
> for at least 15 years now, and I find it very convenient and the
> results very nice.  Quite a few people asked me how I manage to produce
> such nice-looking documents in Word ;-)

So have I, for the most part.  But its undocumented restrictions, in
particular enforcing double line spacing of short @items etc., are not
nice-looking, IMAO.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat. (Patch V2)

[Eli Zaretskii]

> Date: Tue, 28 Apr 2009 22:33:03 +0000
> Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
>   karl@freefriends.org
> From: Alan Mackenzie <acm@muc.de>
> 
> On Mon, Apr 27, 2009 at 09:39:48PM +0300, Eli Zaretskii wrote:
> > > > That's an unusual use of @itemx.  Beware: it could do something you
> > > > didn't intend in some future version of Texinfo.  
> 
> > > I don't think so; at least, not if makeinfo does what its manual
> > > says.  @itemx is defined to be identical to @item, except for not
> > > inserting a blank line.  (See page "itemx" in the manual).
> 
> > That's not what I meant.  I meant that you in effect have here @item's
> > without the text after them.  A @table is not supposed to be like that,
> > so who knows what will the output be?  In particular, HTML and XML
> > outputs may assume there always be some text, and if not, fail to
> > properly close the markup.
> 
> Surely it's not unusual (in any markup language) to have a blank cell in
> a table.  I've generated HTML, and it's fine.  I've generated XML, and it
> looks fine too, as much as XML ever looks fine (though I don't know
> offhand if I've got a suitable viewing program for it).

I had no doubt you tested your changes.  That is why I said that this
might be a problem _in_some_future_version_ of Texinfo, see above.  In
particular, the next version of Texinfo is expected to toss the C
implementation of makeinfo and instead use texi2html, which is a Perl
program.  That means all the undocumented (mis)features of makeinfo
will give way to other undocumented (mis)features.

> Have you never written @example code yourself, where the enforced
> indentation has caused lines to become "too long"?

Sure, but I always find a way to break those into several lines.

> Anyhow, I've put @example in now (as requested by Miles and yourself),
> and split some more lines up.  There are, however, one or two lines which
> go over C74 which can't sensibly be split.

If you show those lines, perhaps someone can suggest a way of
splitting them that does make sense.

Re: Interactive hat. (Patch V2)

[Alan Mackenzie]

Hi, Eli!

On Wed, Apr 29, 2009 at 10:22:09AM +0300, Eli Zaretskii wrote:
> > Date: Tue, 28 Apr 2009 22:33:03 +0000
> > Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org,
> >   karl@freefriends.org
> > From: Alan Mackenzie <acm@muc.de>


> > > That's not what I meant.  I meant that you in effect have here
> > > @item's without the text after them.  A @table is not supposed to
> > > be like that, so who knows what will the output be?  In particular,
> > > HTML and XML outputs may assume there always be some text, and if
> > > not, fail to properly close the markup.

> > Surely it's not unusual (in any markup language) to have a blank cell
> > in a table.  I've generated HTML, and it's fine.  I've generated XML,
> > and it looks fine too, as much as XML ever looks fine (though I don't
> > know offhand if I've got a suitable viewing program for it).

> I had no doubt you tested your changes.  That is why I said that this
> might be a problem _in_some_future_version_ of Texinfo, see above.  In
> particular, the next version of Texinfo is expected to toss the C
> implementation of makeinfo and instead use texi2html, which is a Perl
> program.  That means all the undocumented (mis)features of makeinfo
> will give way to other undocumented (mis)features.

Hmm.  I can foresee there's going to be a lot of gnashing of teeth, lots
of rants like mine written, perhaps a few divorces caused by this coming
change.  I don't think the Info format is quite as simple as it appears.
A lot of projects will just stick with the old C version (i.e. recommend
it to its users), much like Emacs recommends the fairly old Texinfo 4.3
or later.  I think Stefan M.'s approach, face the problem when we come to
it, is the best here.

> > Have you never written @example code yourself, where the enforced
> > indentation has caused lines to become "too long"?

> Sure, but I always find a way to break those into several lines.

> > Anyhow, I've put @example in now (as requested by Miles and
> > yourself), and split some more lines up.  There are, however, one or
> > two lines which go over C74 which can't sensibly be split.

> If you show those lines, perhaps someone can suggest a way of
> splitting them that does make sense.

OK.  Here's a bit from page "Non-string Interactive", exactly as it
appears in the info file after @verbatim has been replaced by @example:

                                                                     70  74
                                                                      |   |
#################################################################################

    `@' - Select window of mouse event
               (interactive
                (let ((events (this-command-keys-vector))
                      e w
                      (i 0))
                  (while (and (< i (length events))
                              (not (consp (setq e (aref events i)))))
                    (setq i (1+ i)))
                  (when (consp e)
                    (setq w (car (cadr e)))
                    (if (windowp w)
                        (if (and (window-minibuffer-p w)
                                 (> (minibuffer-depth) 0))
                            (error
                             "Attempt to select inactive minibuffer window")))
                    (run-hooks mouse-leave-buffer-hook)
                    (select-window w))
                  nil))
          Note that this form only works when the KEYS parameter to
          `call-interactively' (see Interactive Call) is `nil'
          (which it almost always is).

#################################################################################
                                                                      |   |
                                                                     70  74

The "long" string, "Attempt to select inactive minibuffer window" was
taken from Fcall_interactively in callint.c.  But, on the other hand, why
the fuss?  There are menu items which are longer, e.g. this one on page
"Keymaps":

* Scanning Keymaps::            Looking through all keymaps, for printing help.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Interactive hat. (Patch V2)

[Eli Zaretskii]

> Date: Wed, 29 Apr 2009 11:36:02 +0000
> Cc: lekktu@gmail.com, karl@freefriends.org, monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I think Stefan M.'s approach, face the problem when we come to it,
> is the best here.

That approach is best if you cannot reasonably avoid the potential
trouble in the first place.  This isn't the case here.

>                         (if (and (window-minibuffer-p w)
>                                  (> (minibuffer-depth) 0))
>                             (error
>                              "Attempt to select inactive minibuffer window")))

Why is it a problem to outdent this string?  Or do something like
this:

                            (error "Attempt to select \
inactive minibuffer window")))

or this:

                            (error "Attempt to select "
                                   "inactive minibuffer window")))

?

> But, on the other hand, why the fuss?  There are menu items which
> are longer, e.g. this one on page "Keymaps":
> 
> * Scanning Keymaps::            Looking through all keymaps, for printing help.

The problem with long lines exists only in the printed version of the
manual, and only in the `@example' environment, because TeX does not
fill text in this environment as it normally would and produces
exactly one line of output for every input line.

In addition, menus produce no output at all in the printed manual, so
whatever we do there cannot possibly cause line overflow.

Re: Interactive hat. (Patch V2)

[Stefan Monnier]

>> I think Stefan M.'s approach, face the problem when we come to it,
>> is the best here.

Didn't know it was my approach ;-)

> That approach is best if you cannot reasonably avoid the potential
> trouble in the first place.  This isn't the case here.

Also if there's a good case to be made that when/if the problem appears
it will be better solved elsewhere anyway.  E.g. it would be a bug for
the new code to not handle empty table cells properly, so I see no
reason to work around a potential future bug.

> Why is it a problem to outdent this string?  Or do something like
> this:

>                             (error "Attempt to select \
> inactive minibuffer window")))

Yuck!!

> or this:

>                             (error "Attempt to select "
>                                    "inactive minibuffer window")))

This is not the same (`error' passes its arguments to `format').
You need to add `concat' in there.

I'd rather shorten the message, e.g. by dropping " window".
Of course, an even (much) better solution is to move this code into its
own function so the code in the manual can be just a simple call to
that function.


        Stefan