space, M-x

space, M-x

[Gilaras Drakeson]

Hi,

[Since it is hard to know whether a feature has already been implemented
in Emacs, I post this suggestion at the risk of being redundant.]

I am a proponent of tab-completion and history, whenever the user enters
a non-trivial command.  In order to improve the `M-x' behaviour, Emacs
can use whitespace as delimeter. For example:

 M-x set-fill-column M-space 80 RET

should translate to (set-fill-column 80).  Since this is a command, not
merely a function, we can also use the arguments to `interactive' as a
way to do completion for the arguments of the command. For example:

 M-x make-directory M-space ~/<TAB>

could complete directory or file names in a pop-up window.

Obviously there are implementation issues. For instance how to handle
`forms' as argument to `interactive', as that is much harder than
handling something like (interactive "f"). But I think this worth
trying. What do you think?

Gilaras

Re: space, M-x

[Stefan Monnier]

> I am a proponent of tab-completion and history, whenever the user enters
> a non-trivial command.  In order to improve the `M-x' behaviour, Emacs
> can use whitespace as delimeter. For example:

>  M-x set-fill-column M-space 80 RET

This may be marginally more convenient than "C-8 0 M-x set-fill-column
RET" in some cases, indeed (basically in the cases where you've started
M-x before realizing you needed to pass a prefix arg).

> should translate to (set-fill-column 80).  Since this is a command, not
> merely a function, we can also use the arguments to `interactive' as a
> way to do completion for the arguments of the command. For example:

>  M-x make-directory M-space ~/<TAB>

But I don't see what's the point of this one.

   M-x make-directory RET ~/<TAB>

works just as well, doesn't it?

> Obviously there are implementation issues. For instance how to handle
> `forms' as argument to `interactive', as that is much harder than
> handling something like (interactive "f"). But I think this worth
> trying. What do you think?

There is probably something worthwhile to find down this road, but
I think we need to first think harder about which cases coulod beneift
from something like that.
As you say, the implementation might be an issue (and in the form you
suggest above, it's really unclear what the implementation should/could
be), so we'd first need to have a clear idea of what are the important
cases to handle.

As easy thing to do would be to provide a new binding in the M-x
completion that takes a prefix arg, exits from the minibuffer and passes
the prefix arg to the specified command.  But that would only work for
a prefix arg.


        Stefan

Re: space, M-x

[Gilaras Drakeson]

> This may be marginally more convenient than "C-8 0 M-x set-fill-column
> RET" in some cases, indeed (basically in the cases where you've
> started M-x before realizing you needed to pass a prefix arg).

I am looking for two improvements:

One is the ability to enter the arguments "naturally", the way you use a
shell.  It is more comfortable to see the whole command (with arguments)
on the same line/in the same area.  Sometimes the user wants to go back
and edit previous arguments, or even the command name.

The other is to have the command and its arguments in the history.
Imagine that you want to (do-thing arg1-1 arg2), then (do-thing arg1-2
arg2), (do-thing arg1-3 arg2), etc.  Currently doing this can be a
hassle, unless you use eval-expression in which case you lose the other
benefits of M-x, e.g., hand-crafted tab completion. It would be handier
if you could type "replace-regex<Up>" and see the arguments to your
previous invocations of replace-regex.

>>  M-x make-directory M-space ~/<TAB>
>
> But I don't see what's the point of this one.
>
>    M-x make-directory RET ~/<TAB>
>
> works just as well, doesn't it?

Yes, the logical order of entering non-prefix commands are fine.  The
other argument about the history of previous commands still holds,
though.

> There is probably something worthwhile to find down this road, but
> I think we need to first think harder about which cases coulod beneift
> from something like that.
> As you say, the implementation might be an issue (and in the form you
> suggest above, it's really unclear what the implementation should/could
> be), so we'd first need to have a clear idea of what are the important
> cases to handle.
>
> As easy thing to do would be to provide a new binding in the M-x
> completion that takes a prefix arg, exits from the minibuffer and passes
> the prefix arg to the specified command.  But that would only work for
> a prefix arg.

Why not just make whitespace have a meaning there? As we can already
insert a space character with M-space, there won't be a need for a new
key-binding. Just parse the line and split it into command-name and
arguments if it includes any whitespaces. Although this doesn't achieve
the point regarding tab-completion, it will get registered in the
history and is convenient to use when you have already typed in the
command name and now want to decide on the prefix argument.

Gilaras

Re: space, M-x

[Jim Blandy]

On Mon, Nov 10, 2008 at 9:07 AM, Gilaras Drakeson <gilaras@gmail.com> wrote:
>> This may be marginally more convenient than "C-8 0 M-x set-fill-column
>> RET" in some cases, indeed (basically in the cases where you've
>> started M-x before realizing you needed to pass a prefix arg).
>
> I am looking for two improvements:
>
> One is the ability to enter the arguments "naturally", the way you use a
> shell.  It is more comfortable to see the whole command (with arguments)
> on the same line/in the same area.  Sometimes the user wants to go back
> and edit previous arguments, or even the command name.

In the current sources, you can type M-x set-fill-column RET and then
use M-p to find previous values.

> The other is to have the command and its arguments in the history.
> Imagine that you want to (do-thing arg1-1 arg2), then (do-thing arg1-2
> arg2), (do-thing arg1-3 arg2), etc.  Currently doing this can be a
> hassle, unless you use eval-expression in which case you lose the other
> benefits of M-x, e.g., hand-crafted tab completion. It would be handier
> if you could type "replace-regex<Up>" and see the arguments to your
> previous invocations of replace-regex.

You can type M-% replace-regexp RET M-p to see previous regular
expressions, can't you?

>>>  M-x make-directory M-space ~/<TAB>
>>
>> But I don't see what's the point of this one.
>>
>>    M-x make-directory RET ~/<TAB>
>>
>> works just as well, doesn't it?
>
> Yes, the logical order of entering non-prefix commands are fine.  The
> other argument about the history of previous commands still holds,
> though.

M-p works here, too.

Perhaps what you're after here is having Emacs's M-x history behave a
bit more like bash's command history, where stepping back into the
history retrieves both a command and its arguments.

Re: space, M-x

[Stefan Monnier]

> One is the ability to enter the arguments "naturally", the way you use a
> shell.  It is more comfortable to see the whole command (with arguments)
> on the same line/in the same area.  Sometimes the user wants to go back
> and edit previous arguments, or even the command name.

> The other is to have the command and its arguments in the history.
> Imagine that you want to (do-thing arg1-1 arg2), then (do-thing arg1-2
> arg2), (do-thing arg1-3 arg2), etc.  Currently doing this can be a
> hassle, unless you use eval-expression in which case you lose the other
> benefits of M-x, e.g., hand-crafted tab completion. It would be handier
> if you could type "replace-regex<Up>" and see the arguments to your
> previous invocations of replace-regex.

I see what you mean.  repeat-complex-command may be a way to get some of
what you want.  Not that it does just what you want, but I think that
getting really what you want is going to require a lot of work.


        Stefan

Re: space, M-x

[Stephen J. Turnbull]

Jim Blandy writes:

 > Perhaps what you're after here is having Emacs's M-x history behave a
 > bit more like bash's command history, where stepping back into the
 > history retrieves both a command and its arguments.

I use C-x ESC ESC (repeat-complex-command) for that.

Re: space, M-x

[Jim Blandy]

On Thu, Nov 13, 2008 at 7:19 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Jim Blandy writes:
>
>  > Perhaps what you're after here is having Emacs's M-x history behave a
>  > bit more like bash's command history, where stepping back into the
>  > history retrieves both a command and its arguments.
>
> I use C-x ESC ESC (repeat-complex-command) for that.

Right; I never got into that, but it's exactly what's called for.
What's missing is completion as one edits the arguments.  :)

Re: space, M-x

[Stephen J. Turnbull]

Jim Blandy writes:
 > On Thu, Nov 13, 2008 at 7:19 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
 > > Jim Blandy writes:
 > >
 > >  > Perhaps what you're after here is having Emacs's M-x history behave a
 > >  > bit more like bash's command history, where stepping back into the
 > >  > history retrieves both a command and its arguments.
 > >
 > > I use C-x ESC ESC (repeat-complex-command) for that.
 > 
 > Right; I never got into that, but it's exactly what's called for.
 > What's missing is completion as one edits the arguments.  :)

M-TAB works for me most of the time.  However, that *is* a pretty big
step back from the completion you get with most commands, I admit.

It should be possible for repeat-complex-command to have position-
sensitive completion based on the interactive spec (if one exists) of
the closest enclosing function call.  An alternative would be to do
the same thing, but only for the top-level call.  The basic idea for
top-level would be instead of princ'ing the whole sexp, treat it as a
list and wrap each element of the list in a field as you princ it.
Then the field would have a keymap and a history/completion list.
(How history would be maintained is an exercise for the reader, I'm
way too lazy to even *think* about it today. :-)

I have no time to work on this, though.

Re: space, M-x

[Stefan Monnier]

> It should be possible for repeat-complex-command to have position-
> sensitive completion based on the interactive spec (if one exists) of
> the closest enclosing function call.

Yes, I can see it working for commands whose interactive specs take the
form of a string, but if it's a sexp, it seems to stand somewhere between
very difficult and impossible.

Of course, we could supplement function(command) info with completion
info (additionally to the indentation and edebug info) so as not to need
to analyse the sexp (and so it also works for non-commands).


        Stefan