Short explanation for & in key ! of dired

Short explanation for & in key ! of dired

[Daniel Clemente]

  Hi, I think that in the docstring of method dired-do-shell-command (assigned to key !), it would be useful to add a paragraph like:

---
    Emacs will block until the program ends. To execute the command in the background, add `&' to the end of you string, as in `program * &'.
---

  For it's not completely obvious, and it's useful if you're opening graphical programs like xpdf, ooffice, a web browser, ...


  Thanks,

Daniel

Re: Short explanation for & in key ! of dired

[David Kastrup]

Daniel Clemente <dcl441-bugs@yahoo.com> writes:

>   Hi, I think that in the docstring of method dired-do-shell-command (assigned to key !), it would be useful to add a paragraph like:
>
> ---
>     Emacs will block until the program ends. To execute the command in the background, add `&' to the end of you string, as in `program * &'.
> ---
>
>   For it's not completely obvious, and it's useful if you're opening graphical programs like xpdf, ooffice, a web browser, ...

Pity & is already taken for dired-flag-garbage-files.  It would be an
obvious candidate for starting commands in the background.

-- 
David Kastrup

Re: Short explanation for & in key ! of dired

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> Pity & is already taken for dired-flag-garbage-files.  It would be an
> obvious candidate for starting commands in the background.

Yup.

Does anybody use dired-flag-garbage-files?

It seems dangerously vague...

-Miles

-- 
/\ /\
(^.^)
(")")
*This is the cute kitty virus, please copy this into your sig so it can spread.

Re: Short explanation for & in key ! of dired

[Juri Linkov]

>> Pity & is already taken for dired-flag-garbage-files.  It would be an
>> obvious candidate for starting commands in the background.
>
> Yup.
>
> Does anybody use dired-flag-garbage-files?
>
> It seems dangerously vague...

Unlike its counterpart commands `#' (flag auto-save files) and
`~' (flag backup files), the key `&' to flag "garbage" files
is not mnemonic.  The proposed command to execute a dired command
asynchronously has much better mnemonics for `&'.  Then I see
that the key `M-&' is free for the global key binding, so maybe
use it to execute a command asynchronously in any buffer like `M-!'.

Another usual problem for newbies to how to execute multiple
commands asynchronously.  The trick is to rename the existing
buffer *Async Shell Command*, but this is unobvious.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Short explanation for & in key ! of dired

[joakim]

Juri Linkov <juri@jurta.org> writes:

>>> Pity & is already taken for dired-flag-garbage-files.  It would be an
>>> obvious candidate for starting commands in the background.
>>
>> Yup.
>>
>> Does anybody use dired-flag-garbage-files?
>>
>> It seems dangerously vague...
>
> Unlike its counterpart commands `#' (flag auto-save files) and
> `~' (flag backup files), the key `&' to flag "garbage" files
> is not mnemonic.  The proposed command to execute a dired command
> asynchronously has much better mnemonics for `&'.  Then I see
> that the key `M-&' is free for the global key binding, so maybe
> use it to execute a command asynchronously in any buffer like `M-!'.

Sounds great!

> Another usual problem for newbies to how to execute multiple
> commands asynchronously.  The trick is to rename the existing
> buffer *Async Shell Command*, but this is unobvious.

Many times I thought to myself I'd prepare a patch to let the async
buffer be renamed when prefixing c-u, like shell buffers, but I've never
gotten around to it.

-- 
Joakim Verona

Re: Short explanation for & in key ! of dired

[Miles Bader]

joakim@verona.se writes:
>> Another usual problem for newbies to how to execute multiple
>> commands asynchronously.  The trick is to rename the existing
>> buffer *Async Shell Command*, but this is unobvious.
>
> Many times I thought to myself I'd prepare a patch to let the async
> buffer be renamed when prefixing c-u, like shell buffers, but I've never
> gotten around to it.

I'd like C-u to just discard output, since 99% of the time, that's what
people really want these days.  Actually I'd like to make that default.

-Miles

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

Re: Short explanation for & in key ! of dired

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> joakim@verona.se writes:
>>> Another usual problem for newbies to how to execute multiple
>>> commands asynchronously.  The trick is to rename the existing
>>> buffer *Async Shell Command*, but this is unobvious.
>>
>> Many times I thought to myself I'd prepare a patch to let the async
>> buffer be renamed when prefixing c-u, like shell buffers, but I've never
>> gotten around to it.
>
> I'd like C-u to just discard output, since 99% of the time, that's what
> people really want these days.  Actually I'd like to make that default.

If I want different commands accumulating asynchronous output, I'll open
shell buffers for them.  When I start a command asynchronously, I don't
want it interfering with my normal operation.  The asynchronous buffer
is a nuisance in that regard.  It's also a nuisance that commands
started that way will die together with Emacs when Emacs is stopped.

If we gain a new command M-&, I would not particularly mind the current
M-! behavior for background commands (I would just likely never use it).
But I definitely would want to have M-& to dissociate the commands it
starts.  That would be a new command, yes, not a variation of the old
one.  I can live with that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Short explanation for & in key ! of dired

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> If we gain a new command M-&, I would not particularly mind the
> current M-! behavior for background commands (I would just likely
> never use it).

That was less than clear: I meant that I would not mind if M-! retained
its current behavior for commands ending in & as long as M-& does not
behave the same.

> But I definitely would want to have M-& to dissociate the commands it
> starts.  That would be a new command, yes, not a variation of the old
> one.  I can live with that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Short explanation for & in key ! of dired

[joakim]

David Kastrup <dak@gnu.org> writes:

> Miles Bader <miles.bader@necel.com> writes:
>
>> joakim@verona.se writes:
>>>> Another usual problem for newbies to how to execute multiple
>>>> commands asynchronously.  The trick is to rename the existing
>>>> buffer *Async Shell Command*, but this is unobvious.
>>>
>>> Many times I thought to myself I'd prepare a patch to let the async
>>> buffer be renamed when prefixing c-u, like shell buffers, but I've never
>>> gotten around to it.
>>
>> I'd like C-u to just discard output, since 99% of the time, that's what
>> people really want these days.  Actually I'd like to make that default.
>
> If I want different commands accumulating asynchronous output, I'll open
> shell buffers for them.  When I start a command asynchronously, I don't
> want it interfering with my normal operation.  The asynchronous buffer
> is a nuisance in that regard.  It's also a nuisance that commands
> started that way will die together with Emacs when Emacs is stopped.
>
> If we gain a new command M-&, I would not particularly mind the current
> M-! behavior for background commands (I would just likely never use it).
> But I definitely would want to have M-& to dissociate the commands it
> starts.  That would be a new command, yes, not a variation of the old
> one.  I can live with that.

To clarify, I use ! in dired to start things like Gimp, Inkscape
Gqcomicbook, and Evince on files. I want those to be backgrounded and I
want to bea ble to run more than one instance. I'm not super-interested
in command output, but it wont hurt either.

To achieve this I today have to do this in dired:

! gimp ? & RET
m-x rename-buffer gimpbuf1 RET

If this could be reduced to:

& gimp RET

I'd be happier! But, ok, thats my use-case, and I dont really know how
other people use dired. 
-- 
Joakim Verona

Re: Short explanation for & in key ! of dired

[Miles Bader]

joakim@verona.se writes:
> & gimp RET
>
> I'd be happier! But, ok, thats my use-case, and I dont really know how
> other people use dired. 

That's exactly what I want too.  When backgrounding, I'm almost always
running some gui app; I do not care about stdout/stderr, and Emacs
clumsy handling of background processes (only one at a time unless you
fiddle with things) is pretty annoying.

The current behavior of backgrounding seems vaguely anacronistic, maybe
from a time when people didn't use a window system.

Incidentally, many gnome apps are extremely sloppy about their output --
if you run them from a terminal you get tons of random debugging junk
(which doesn't for the most part seem to reflect any observable
problem).  This is for standard released apps.  It seems that they are
expected to normally be run in an environment where such output is
discarded.

-miles

-- 
The automobile has not merely taken over the street, it has dissolved the
living tissue of the city.  Its appetite for space is absolutely insatiable;
moving and parked, it devours urban land, leaving the buildings as mere
islands of habitable space in a sea of dangerous and ugly traffic.
[James Marston Fitch, New York Times, 1 May 1960]

Re: Short explanation for & in key ! of dired

[joakim]

Miles Bader <miles.bader@necel.com> writes:

> joakim@verona.se writes:
>> & gimp RET
>>
>> I'd be happier! But, ok, thats my use-case, and I dont really know how
>> other people use dired. 
>
> That's exactly what I want too.  When backgrounding, I'm almost always
> running some gui app; I do not care about stdout/stderr, and Emacs
> clumsy handling of background processes (only one at a time unless you
> fiddle with things) is pretty annoying.
>
> The current behavior of backgrounding seems vaguely anacronistic, maybe
> from a time when people didn't use a window system.
>
> Incidentally, many gnome apps are extremely sloppy about their output --
> if you run them from a terminal you get tons of random debugging junk
> (which doesn't for the most part seem to reflect any observable
> problem).  This is for standard released apps.  It seems that they are
> expected to normally be run in an environment where such output is
> discarded.

Exactly my observation too. But sometimes you still need to see the
output when debugging, often post-mortem, so to speak. For instance I
tried gnome-sudoku the other day, and it didnt work properly, and I had
to look at the output to discover it failed on missing files.

In the end, the proper solution was to install the emacs sudoku client
of course :)


>
> -miles



-- 
Joakim Verona

Re: Short explanation for & in key ! of dired

[Paul R]

joakim@verona.se writes:

>>> I'd be happier! But, ok, thats my use-case, and I dont really know how
>>> other people use dired. 
>>
>> That's exactly what I want too.  When backgrounding, I'm almost always
>> running some gui app; I do not care about stdout/stderr, and Emacs
>> clumsy handling of background processes (only one at a time unless you
>> fiddle with things) is pretty annoying.

That's my use case as well. Since we usually don't want to read
stdout/stderr, we could have a flag to redirect them to /dev/null.
Also, I think we can safely set defaults so that stdout is printed,
and stderr is discarded.

-- 
      Paul

Re: Short explanation for & in key ! of dired

[Lynbech Christian]

>>>>> "joakim" == joakim  <joakim@verona.se> writes:

joakim> Exactly my observation too. But sometimes you still need to see the
joakim> output when debugging, often post-mortem, so to speak.

i would like to add a "me too" here.

I am also not interested in output for GUI apps, *except* when something
goes wrong, then I often find that I wished for the output.

A possible middle ground would be to redirect output to a temporary
file. then it will not affect emacs and still be available for
debugging, should the need arise.

Emacs should (IMHO) remove the file when the application quits, but as
long as the files are accumulated in /tmp or equivalent, it is not a
terrible disaster if such output files is left behind from time to
time. 

A middle middle ground would be to only redirect either stdout or
stderr, leaving the other as output into a buffer in the hope that it
will actually only contain important messages with the junk going
elsewhere.

Yet another option would be to offer to display the file (if nonzero)
when the application quits, sort of giving the best of both worlds and
something that would also work for the case where the app is not a GUI
but something providing usefull output (such as find or grep).

------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: Short explanation for & in key ! of dired

[David Kastrup]

Lynbech Christian <christian.lynbech@tietoenator.com> writes:

>>>>>> "joakim" == joakim  <joakim@verona.se> writes:
>
> joakim> Exactly my observation too. But sometimes you still need to see the
> joakim> output when debugging, often post-mortem, so to speak.
>
> i would like to add a "me too" here.
>
> I am also not interested in output for GUI apps, *except* when something
> goes wrong, then I often find that I wished for the output.
>
> A possible middle ground would be to redirect output to a temporary
> file. then it will not affect emacs and still be available for
> debugging, should the need arise.

One temporary non-saved buffer for all that does not accumulate more
than a specified maximum (similar to *Messages*) should be fine, I
think.

-- 
David Kastrup

Re: Short explanation for & in key ! of dired

[Phil Jackson]

David Kastrup <dak@gnu.org> writes:

>> A possible middle ground would be to redirect output to a temporary
>> file. then it will not affect emacs and still be available for
>> debugging, should the need arise.
>
> One temporary non-saved buffer for all that does not accumulate more
> than a specified maximum (similar to *Messages*) should be fine, I
> think.

This one gets my vote. It would be handy to have stdout/err
distinguished with differing faces too.

Cheers,
Phil
-- 
 Philip Jackson
 http://www.shellarchive.co.uk

Re: Short explanation for & in key ! of dired

[Juri Linkov]

> Lynbech Christian <christian.lynbech@tietoenator.com> writes:
>
>>>>>>> "joakim" == joakim  <joakim@verona.se> writes:
>>
>> joakim> Exactly my observation too. But sometimes you still need to see the
>> joakim> output when debugging, often post-mortem, so to speak.
>>
>> i would like to add a "me too" here.
>>
>> I am also not interested in output for GUI apps, *except* when something
>> goes wrong, then I often find that I wished for the output.
>>
>> A possible middle ground would be to redirect output to a temporary
>> file. then it will not affect emacs and still be available for
>> debugging, should the need arise.
>
> One temporary non-saved buffer for all that does not accumulate more
> than a specified maximum (similar to *Messages*) should be fine, I
> think.

Everyone has different needs in different circumstances.  I often execute
long-running programs in background and want to see their output, but
don't care about output when running GUI apps.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Short explanation for & in key ! of dired

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> One temporary non-saved buffer for all that does not accumulate more
>> than a specified maximum (similar to *Messages*) should be fine, I
>> think.
>
> Everyone has different needs in different circumstances.  I often execute
> long-running programs in background and want to see their output, but
> don't care about output when running GUI apps.

Ther could be a variable (e.g. "command-name-default-discard-output")
which controls that behavior, and C-u could invert the sense of that
default.

When _not_ discarding output, I think in general it should (1) always
make a new buffer (to allow convenient use of multiple simultaneous
background commands), and (2) maybe bury the buffer at first.

That might satisfy all the viewpoints expressed thus far
(you:  default nil, C-u for occasional gui app, me: default t, C-u for debugging).

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Short explanation for & in key ! of dired

[Juri Linkov]

> Ther could be a variable (e.g. "command-name-default-discard-output")
> which controls that behavior, and C-u could invert the sense of that
> default.
>
> When _not_ discarding output, I think in general it should (1) always
> make a new buffer (to allow convenient use of multiple simultaneous
> background commands),

Making a new buffer on every run will quickly overpopulate the buffer list
with a lot of buffers with exited processes.  Maybe it should check the
running process status of the default buffer before creating a new one.
So instead of asking a question "A command is running.  Kill it? "
just silently run the command it a new buffer.  And reuse the default
buffer when it doesn't run a process.

> and (2) maybe bury the buffer at first.
>
> That might satisfy all the viewpoints expressed thus far
> (you:  default nil, C-u for occasional gui app, me: default t, C-u for debugging).

I agree with the need for a new option and the C-u argument, but with
a slightly different meaning.  Sometimes I need to inspect the output of
misbehaving GUI app and would like to do this without restarting it with C-u.
I'd prefer if a new option and C-u defined whether to show or hide
the associated process buffer.  So when running GUI app with C-u, it could
bury the buffer, but when running a command line tool, then show its
output like it does now.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Short explanation for & in key ! of dired

[Mathias Dahl]

> To achieve this I today have to do this in dired:
>
> ! gimp ? & RET

Speaking of Gimp, and going a bit off-topic here, can anyone explain
why I cannot seem to run gimp-remote in the same fashion? I do this:

! gimp-remote ? &

And it finishes right away without opening Gimp. The only way I can
start it is by doing:

! gimp-remote

But for some reason that locks up Emacs, although that does not happen
if I run it from Bash.

Is this an issue in gimp-remote, Emacs, or a combination?

/Mathias

Re: Short explanation for & in key ! of dired

[Stefan Monnier]

>> To achieve this I today have to do this in dired:
>> ! gimp ? & RET

> Speaking of Gimp, and going a bit off-topic here, can anyone explain
> why I cannot seem to run gimp-remote in the same fashion? I do this:

> ! gimp-remote ? &

> And it finishes right away without opening Gimp. The only way I can
> start it is by doing:

> ! gimp-remote

> But for some reason that locks up Emacs, although that does not happen
> if I run it from Bash.

> Is this an issue in gimp-remote, Emacs, or a combination?

My guess is that gimp-remote does a "fork&exit" and then does its task.

So "gimp-remote ? &" fails because as soon as the async process exits,
Emacs will close the pipe to that process, which is apparently kills the
forked process as well.

And inversely "gimp-remote" fails to terminate because Emacs's sync
processes wait for the proces to close stdin&stdout, but the forked
process still running doesn't close them, for some reason.

Hopefully we can make Emacs behave more like regular shells, but I don't
know enough about Unix process programming to fix it.  Any taker?


        Stefan

& and M-& to run programs asynchronously (was: Re: Short explanation for & in key ! of dired)

[Daniel Clemente]

  What's the status of this feature? Several problems were tackled and several suggestions were proposed, but no consensus was reached.

  Discussion brought following topics:

- & in dired is not intuitive for dired-flag-garbage-files
- & in dired could be used to open in background a command which affects the selected file. Ex: & gimp RET
- M-& could be like M-! but opening the program asynchronously (in background)
- M-! or M-& use always the same buffer to show their output. This can be confusing
- C-u M-! or C-u M-& could be used to create a new buffer for the output
- C-u M-! or C-u M-& could be used to discard output
- M-& could dissociate the started commands so they persist after killing Emacs
- M-! with a & at the end could have a different behaviour than M-&: M-& to dissociate commands, M-! & to not do it
- the current behaviour of backgrounding seems anachronistic since nowadays it's very normal to open graphical programs which show no output and need to stay in background
- sometimes the output of a command is needed, even of a graphical command
- we could have a flag to redirect stdout to stderr, and show only stdout
- we could redirect stdout to a temporary file, for instance in /tmp, and delete it when Emacs quits
- we could offer to see the output each time that a background program which produced output ends 
- we could redirect all output to a temporary buffer like *Messages*
- stdout/stderr should be somehow distinguished (faces, ...)
- a variable could decide if the output is needed, and C-u could negate this setting
- if we use a different output buffer for each program, old buffers (of ended programs) could be reused


  It was spoken about different use cases. I have seen 4 of them:

|                                | UC1 | UC2 | UC3 | UC4 |
|--------------------------------+-----+-----+-----+-----|
| Execute in background?         |     | t   | t   | t   |
| Output visible?                | t   |     | t   | t   |
| New buffer for each & command? |     |     |     | t   |

  Examples:
- UC1: M-! date. Note that when run in foreground, output will always be displayed, and only one buffer will be used
- UC2: ...M-& gimp. (You need no output)
- UC3: ...M-& glxgears.  (It displays output to stdout)
- UC4: ...M-& bzr up, and then M-& svn up. (You need different outputs)

  Some switches are needed to select the desired behaviour. Following options were suggested:
- a variable
- C-u
- a question after the command has ended

  Places to store the output in:
- a buffer like *Messages*
- a temporary file

  Note that there are different commands to enhance:
- & in dired
- M-& in the global map
- and the documentation!


--
     Daniel

Re: & and M-& to run programs asynchronously

[David Kastrup]

Daniel Clemente <dcl441-bugs@yahoo.com> writes:

>   What's the status of this feature? Several problems were tackled and several suggestions were proposed, but no consensus was reached.
>
>   Discussion brought following topics:
>
> - & in dired is not intuitive for dired-flag-garbage-files

Some alternatives that are not taken are ",", "@", "'", "`".  The
garbage bag symbol "@" might be suitable.

-- 
David Kastrup

Re: & and M-& to run programs asynchronously

[Juri Linkov]

> Daniel Clemente <dcl441-bugs@yahoo.com> writes:
>
>>   What's the status of this feature? Several problems were tackled and several suggestions were proposed, but no consensus was reached.
>>
>>   Discussion brought following topics:
>>
>> - & in dired is not intuitive for dired-flag-garbage-files
>
> Some alternatives that are not taken are ",", "@", "'", "`".  The
> garbage bag symbol "@" might be suitable.

Garbage bag?!  It is a human in NetHack.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> Daniel Clemente <dcl441-bugs@yahoo.com> writes:
>>
>>>   What's the status of this feature? Several problems were tackled
>>>   and several suggestions were proposed, but no consensus was
>>>   reached.
>>>
>>>   Discussion brought following topics:
>>>
>>> - & in dired is not intuitive for dired-flag-garbage-files
>>
>> Some alternatives that are not taken are ",", "@", "'", "`".  The
>> garbage bag symbol "@" might be suitable.
>
> Garbage bag?!  It is a human in NetHack.

And & is a demon.  And ! is a potion.  And hjkl are homunculi, jaguars,
killer bees and leocrottae (or even worse, vi motion commands).

I don't think we should let our keybindings be influenced all too much
by Nethack.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: & and M-& to run programs asynchronously

[Juri Linkov]

>>>>   What's the status of this feature? Several problems were tackled
>>>>   and several suggestions were proposed, but no consensus was
>>>>   reached.
>>>>
>>>>   Discussion brought following topics:
>>>>
>>>> - & in dired is not intuitive for dired-flag-garbage-files
>>>
>>> Some alternatives that are not taken are ",", "@", "'", "`".  The
>>> garbage bag symbol "@" might be suitable.
>>
>> Garbage bag?!  It is a human in NetHack.
>
> And & is a demon.

This suggests leaving the character & for garbage files unchanged.

But seriously, if `% d' is used to flag a group of files for deletion,
then maybe we can bind `% &' to flagging garbage files instead of `&'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
> But seriously, if `% d' is used to flag a group of files for deletion,
> then maybe we can bind `% &' to flagging garbage files instead of `&'?

How about "% g"?

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: & and M-& to run programs asynchronously

[Juri Linkov]

>> But seriously, if `% d' is used to flag a group of files for deletion,
>> then maybe we can bind `% &' to flagging garbage files instead of `&'?
>
> How about "% g"?

It is easy to remember, but I see it is already bound:

% g             dired-mark-files-containing-regexp

where `g' seems to mean `grep'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Edward O'Connor]

Juri Linkov wrote:

>>> But seriously, if `% d' is used to flag a group of files for
>>> deletion, then maybe we can bind `% &' to flagging garbage files
>>> instead of `&'?
>>
>> How about "% g"?
>
> It is easy to remember, but I see it is already bound:
>
> % g             dired-mark-files-containing-regexp
>
> where `g' seems to mean `grep'.

Indeed. I use this binding several times a day! :)


-- 
Edward O'Connor
hober0@gmail.com

Re: & and M-& to run programs asynchronously

[Juri Linkov]

>>> How about "% g"?
>>
>> It is easy to remember, but I see it is already bound:
>>
>> % g             dired-mark-files-containing-regexp
>>
>> where `g' seems to mean `grep'.
>
> Indeed. I use this binding several times a day! :)

But isn't it too slow?  I'd prefer the real `grep' doing the same job.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Edward O'Connor]

>>> % g             dired-mark-files-containing-regexp
>>> where `g' seems to mean `grep'.
>> Indeed. I use this binding several times a day! :)
> But isn't it too slow?  I'd prefer the real `grep' doing the same job.

Well, 90% of the time, I follow it up with Q,
`dired-do-query-replace-regexp'. So the benefit of '% g' is that it
marks the matching files for subsequent dired commands.


-- 
Ted

Re: & and M-& to run programs asynchronously

[Juri Linkov]

> - C-u M-! or C-u M-& could be used to create a new buffer for the output

Another idea is to use a numeric argument like in *shell*,
e.g. `C-u 42 M-!' or `C-u 42 M-&' to add a suffix "<42>"
to the buffer name.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Daniel Clemente]

What's the first step to do this pack of features? (See parent).
  I propose: freeing & key in dired.
  For that, a new key to flag garbage files in dired has to be found.


Daniel

Re: & and M-& to run programs asynchronously

[Juri Linkov]

> What's the first step to do this pack of features? (See parent).
>   I propose: freeing & key in dired.
>   For that, a new key to flag garbage files in dired has to be found.

I see no better key than moving the current key `&' to the `%' prefix.

This prefix is intended for regexp commands.  And `dired-flag-garbage-files'
is a regexp command: it uses `dired-flag-files-regexp' to flag files
that match `dired-garbage-files-regexp'.

We could even improve the command `dired-flag-garbage-files' to allow the
user to modify its default regexp value in the minibuffer after typing `% &'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Daniel Clemente]

>
> I see no better key than moving the current key `&' to the `%' prefix.
>
> This prefix is intended for regexp commands.  And `dired-flag-garbage-files'
> is a regexp command: it uses `dired-flag-files-regexp' to flag files
> that match `dired-garbage-files-regexp'.
>

  I see this as a very good idea. % & to flag garbage files in dired.

> We could even improve the command `dired-flag-garbage-files' to allow the
> user to modify its default regexp value in the minibuffer after typing `% &'.
>

  Maybe just if you prefix it with C-u ?

Re: & and M-& to run programs asynchronously

[Juri Linkov]

>> I see no better key than moving the current key `&' to the `%' prefix.
>>
>> This prefix is intended for regexp commands.  And `dired-flag-garbage-files'
>> is a regexp command: it uses `dired-flag-files-regexp' to flag files
>> that match `dired-garbage-files-regexp'.
>
>   I see this as a very good idea. % & to flag garbage files in dired.
>
>> We could even improve the command `dired-flag-garbage-files' to allow the
>> user to modify its default regexp value in the minibuffer after typing `% &'.
>
>   Maybe just if you prefix it with C-u ?

C-u will make it inconsistent with a similar command % m (`dired-mark-files-regexp')
where a prefix argument means to *unmark* files matching a regexp.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Mathias Dahl]

>>> We could even improve the command `dired-flag-garbage-files' to allow the
>>> user to modify its default regexp value in the minibuffer after typing `% &'.
>>
>>   Maybe just if you prefix it with C-u ?
>
> C-u will make it inconsistent with a similar command % m (`dired-mark-files-regexp')
> where a prefix argument means to *unmark* files matching a regexp.

So does % g, but % d does not. And I don't see that it should it be a
problem considering that `dired-flag-garbage-files' does not use the
prefix argument today. We decide what it should do.

Re: & and M-& to run programs asynchronously

[Juri Linkov]

>>>> We could even improve the command `dired-flag-garbage-files' to allow the
>>>> user to modify its default regexp value in the minibuffer after typing `% &'.
>>>
>>>   Maybe just if you prefix it with C-u ?
>>
>> C-u will make it inconsistent with a similar command % m (`dired-mark-files-regexp')
>> where a prefix argument means to *unmark* files matching a regexp.
>
> So does % g, but % d does not. And I don't see that it should it be a
> problem considering that `dired-flag-garbage-files' does not use the
> prefix argument today. We decide what it should do.

Right, so let's not worry about arguments of `dired-flag-garbage-files' now.

So below is an initial version of a new command `dired-do-async-shell-command'.
Its name is formed by analogy with the buffer name "*Async Shell Command*".
Currently it simply adds & at the end of the asynchronous command.

As for not asking a question "A command is running.  Kill it? "
I think this should be implemented with a new option in simple.el.

Index: lisp/dired.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired.el,v
retrieving revision 1.402
diff -c -r1.402 dired.el
*** lisp/dired.el	19 Jul 2008 23:55:41 -0000	1.402
--- lisp/dired.el	22 Jul 2008 22:47:37 -0000
***************
*** 1194,1200 ****
      (define-key map "#" 'dired-flag-auto-save-files)
      (define-key map "." 'dired-clean-directory)
      (define-key map "~" 'dired-flag-backup-files)
-     (define-key map "&" 'dired-flag-garbage-files)
      ;; Upper case keys (except !) for operating on the marked files
      (define-key map "A" 'dired-do-search)
      (define-key map "C" 'dired-do-copy)
--- 1195,1200 ----
***************
*** 1213,1218 ****
--- 1213,1219 ----
      (define-key map "X" 'dired-do-shell-command)
      (define-key map "Z" 'dired-do-compress)
      (define-key map "!" 'dired-do-shell-command)
+     (define-key map "&" 'dired-do-async-shell-command)
      ;; Comparison commands
      (define-key map "=" 'dired-diff)
      (define-key map "\M-=" 'dired-backup-diff)
***************
*** 1240,1245 ****
--- 1241,1247 ----
      (define-key map "%H" 'dired-do-hardlink-regexp)
      (define-key map "%R" 'dired-do-rename-regexp)
      (define-key map "%S" 'dired-do-symlink-regexp)
+     (define-key map "%&" 'dired-flag-garbage-files)
      ;; Commands for marking and unmarking.
      (define-key map "*" nil)
      (define-key map "**" 'dired-mark-executables)

Index: lisp/dired-aux.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired-aux.el,v
retrieving revision 1.170
diff -c -r1.170 dired-aux.el
*** lisp/dired-aux.el	6 May 2008 07:57:30 -0000	1.170
--- lisp/dired-aux.el	22 Jul 2008 22:43:45 -0000
***************
*** 490,495 ****
--- 490,515 ----
       (format prompt (dired-mark-prompt arg files))
       nil nil)))
  
+ ;;;###autoload
+ (defun dired-do-async-shell-command (command &optional arg file-list)
+   "Run a shell command COMMAND on the marked files asynchronously.
+ 
+ Like `dired-do-shell-command', but if COMMAND doesn't end in ampersand,
+ adds ampersand and executes the command asynchronously.
+ The output appears in the buffer `*Async Shell Command*'."
+   (interactive
+    (let ((files (dired-get-marked-files t current-prefix-arg)))
+      (list
+       ;; Want to give feedback whether this file or marked files are used:
+       (dired-read-shell-command "& on %s: " current-prefix-arg files)
+       current-prefix-arg
+       files)))
+   (unless (string-match "[*?][ \t]*\\'" command)
+     (setq command (concat command " *")))
+   (unless (string-match "&[ \t]*\\'" command)
+     (setq command (concat command " &")))
+   (dired-do-shell-command command arg file-list))
+ 
  ;; The in-background argument is only needed in Emacs 18 where
  ;; shell-command doesn't understand an appended ampersand `&'.
  ;;;###autoload

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Daniel Clemente]

Thanks for the patch to bind & to dired-do-async-shell-command in dired.

I suppose the next step is to do the same for async-shell-command and bind it to M-&
That's in simple.el. A function can read the user's input, add "&", and pass the command to shell-command.


--
Daniel

Re: & and M-& to run programs asynchronously

[Juri Linkov]

> Thanks for the patch to bind & to dired-do-async-shell-command in dired.

It is installed now.

> I suppose the next step is to do the same for async-shell-command and bind it to M-&
> That's in simple.el. A function can read the user's input, add "&",
> and pass the command to shell-command.

This can be done with the following patch that adds a new command
`async-shell-command'.  I also noticed that code that sets
`minibuffer-default-add-shell-commands' could be moved from the
interactive spec of `shell-command' to `read-shell-command' so this
feature will be available for all functions that read a shell command
from the minibuffer (including a new command `async-shell-command').

Index: lisp/bindings.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.209
diff -c -r1.209 bindings.el
*** lisp/bindings.el	30 Jun 2008 19:37:02 -0000	1.209
--- lisp/bindings.el	29 Jul 2008 16:48:03 -0000
***************
*** 746,751 ****
--- 749,755 ----
  
  (define-key esc-map "!" 'shell-command)
  (define-key esc-map "|" 'shell-command-on-region)
+ (define-key esc-map "&" 'async-shell-command)
  
  (define-key ctl-x-map [right] 'next-buffer)
  (define-key ctl-x-map [C-right] 'next-buffer)

Index: lisp/simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.939
diff -c -r1.939 simple.el
*** lisp/simple.el	27 Jul 2008 18:24:31 -0000	1.939
--- lisp/simple.el	29 Jul 2008 16:46:20 -0000
***************
*** 2011,2021 ****
  The arguments are the same as the ones of `read-from-minibuffer',
  except READ and KEYMAP are missing and HIST defaults
  to `shell-command-history'."
!   (apply 'read-from-minibuffer prompt initial-contents
!          minibuffer-local-shell-command-map
!          nil
!          (or hist 'shell-command-history)
!          args))
  
  (defun shell-command (command &optional output-buffer error-buffer)
    "Execute string COMMAND in inferior shell; display output, if any.
--- 2004,2035 ----
  The arguments are the same as the ones of `read-from-minibuffer',
  except READ and KEYMAP are missing and HIST defaults
  to `shell-command-history'."
!   (minibuffer-with-setup-hook
!       (lambda ()
! 	(set (make-local-variable 'minibuffer-default-add-function)
! 	     'minibuffer-default-add-shell-commands))
!     (apply 'read-from-minibuffer prompt initial-contents
! 	   minibuffer-local-shell-command-map
! 	   nil
! 	   (or hist 'shell-command-history)
! 	   args)))
! 
! (defun async-shell-command (command &optional output-buffer error-buffer)
!   "Execute string COMMAND asynchronously.
! 
! Like `shell-command' but if COMMAND doesn't end in ampersand, adds `&'
! surrounded by whitespace and executes the command asynchronously.
! The output appears in the buffer `*Async Shell Command*'."
!   (interactive
!    (list
!     (read-shell-command "Async shell command: " nil nil
! 			(and buffer-file-name
! 			     (file-relative-name buffer-file-name)))
!     current-prefix-arg
!     shell-command-default-error-buffer))
!   (unless (string-match "&[ \t]*\\'" command)
!     (setq command (concat command " &")))
!   (shell-command command output-buffer error-buffer))
  
  (defun shell-command (command &optional output-buffer error-buffer)
    "Execute string COMMAND in inferior shell; display output, if any.
***************
*** 2069,2081 ****
  
    (interactive
     (list
!     (minibuffer-with-setup-hook
! 	(lambda ()
! 	  (set (make-local-variable 'minibuffer-default-add-function)
! 	       'minibuffer-default-add-shell-commands))
!       (read-shell-command "Shell command: " nil nil
! 			  (and buffer-file-name
! 			       (file-relative-name buffer-file-name))))
      current-prefix-arg
      shell-command-default-error-buffer))
    ;; Look for a handler in case default-directory is a remote file name.
--- 2083,2091 ----
  
    (interactive
     (list
!     (read-shell-command "Shell command: " nil nil
! 			(and buffer-file-name
! 			     (file-relative-name buffer-file-name)))
      current-prefix-arg
      shell-command-default-error-buffer))
    ;; Look for a handler in case default-directory is a remote file name.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Chong Yidong]

Juri Linkov <juri@jurta.org> writes:

>> I suppose the next step is to do the same for async-shell-command and
>> bind it to M-& That's in simple.el. A function can read the user's
>> input, add "&", and pass the command to shell-command.
>
> This can be done with the following patch that adds a new command
> `async-shell-command'.  I also noticed that code that sets
> `minibuffer-default-add-shell-commands' could be moved from the
> interactive spec of `shell-command' to `read-shell-command' so this
> feature will be available for all functions that read a shell command
> from the minibuffer (including a new command `async-shell-command').

This is not such a trivial change, since M-& is bound elsewhere in a
couple of modes.  Let's leave this for after the release.

Re: & and M-& to run programs asynchronously

[Juri Linkov]

>>> I suppose the next step is to do the same for async-shell-command and
>>> bind it to M-& That's in simple.el. A function can read the user's
>>> input, add "&", and pass the command to shell-command.
>>
>> This can be done with the following patch that adds a new command
>> `async-shell-command'.  I also noticed that code that sets
>> `minibuffer-default-add-shell-commands' could be moved from the
>> interactive spec of `shell-command' to `read-shell-command' so this
>> feature will be available for all functions that read a shell command
>> from the minibuffer (including a new command `async-shell-command').
>
> This is not such a trivial change, since M-& is bound elsewhere in a
> couple of modes.

I know only that it is bound in the Gnus Summary buffer.  But Gnus is
notorious for its abuse of keybindings, so I think this should not be
a reason not to use `M-&' globally.

> Let's leave this for after the release.

There is no hurry with this, so we could install only a new command
without a keybinding, or postpone everything for after the release.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Daniel Clemente]

Juri Linkov <juri@jurta.org> writes:

>
>> Let's leave this for after the release.
>
> There is no hurry with this, so we could install only a new command
> without a keybinding, or postpone everything for after the release.
>

  I see that the new behaviour for & in dired was added. Could the documentation for ! (dired-do-shell-command) mention the way of executing a command in background? I think this is important because it is not obvious.

  I attach the proposed change; please improve the wording as needed..
  Thanks

--- dired-aux.el	14 ago 2008 20:56:23 +0200	1.179
+++ dired-aux.el	18 ago 2008 02:13:41 +0200	
@@ -551,6 +551,10 @@
 there's no telling what files COMMAND may have changed.
 Type \\[dired-do-redisplay] to redisplay the marked files.
 
+Emacs will block until the command ends. To execute the command
+in background, add `&' to the end of COMMAND, or use
+\\[dired-do-async-shell-command] instead.
+
 When COMMAND runs, its working directory is the top-level directory of
 the Dired buffer, so output files usually are created there instead of
 in a subdir.

Re: & and M-& to run programs asynchronously

[Juri Linkov]

>   I see that the new behaviour for & in dired was added. Could the documentation for ! (dired-do-shell-command) mention the way of executing a command in background? I think this is important because it is not obvious.
>
>   I attach the proposed change; please improve the wording as needed..
>   Thanks
>
> --- dired-aux.el	14 ago 2008 20:56:23 +0200	1.179
> +++ dired-aux.el	18 ago 2008 02:13:41 +0200
> @@ -551,6 +551,10 @@
>  there's no telling what files COMMAND may have changed.
>  Type \\[dired-do-redisplay] to redisplay the marked files.
>
> +Emacs will block until the command ends. To execute the command
> +in background, add `&' to the end of COMMAND, or use
> +\\[dired-do-async-shell-command] instead.
> +
>  When COMMAND runs, its working directory is the top-level directory of
>  the Dired buffer, so output files usually are created there instead of
>  in a subdir.

There is no term "background" in the existing Emacs documentation,
so it is better to use the term "asynchronously" like in the
docstring of `shell-command':

Index: lisp/dired-aux.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/dired-aux.el,v
retrieving revision 1.179
diff -c -r1.179 dired-aux.el
*** lisp/dired-aux.el	31 Jul 2008 17:17:35 -0000	1.179
--- lisp/dired-aux.el	25 Aug 2008 19:48:40 -0000
***************
*** 545,551 ****
  normally to the shell, but you must confirm first.  To pass `*' by
  itself to the shell as a wildcard, type `*\"\"'.
  
! If COMMAND produces output, it goes to a separate buffer.
  
  This feature does not try to redisplay Dired buffers afterward, as
  there's no telling what files COMMAND may have changed.
--- 548,558 ----
  normally to the shell, but you must confirm first.  To pass `*' by
  itself to the shell as a wildcard, type `*\"\"'.
  
! If COMMAND ends in ampersand, it is executed asynchronously
! and the output appears in the buffer `*Async Shell Command*'
! \(you can also use \\[dired-do-async-shell-command]).
! Otherwise, COMMAND is executed synchronously and the output
! appears in the buffer `*Shell Command Output*'.
  
  This feature does not try to redisplay Dired buffers afterward, as
  there's no telling what files COMMAND may have changed.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Daniel Clemente]

Juri Linkov <juri@jurta.org> writes:

>
> There is no term "background" in the existing Emacs documentation,
> so it is better to use the term "asynchronously" like in the
> docstring of `shell-command':
>

  Ok. But I find „the program executes synchronously“ not so descriptive as saying that „Emacs remains blocked until the program ends“. Many users will be reading that documentation when they wonder why Emacs is blocked after opening evince or firefox.

Re: & and M-& to run programs asynchronously

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Aug 25, 2008 at 10:52:17PM +0300, Juri Linkov wrote:

[...]

> There is no term "background" in the existing Emacs documentation,
> so it is better to use the term "asynchronously" like in the
> docstring of `shell-command':

Still, may I suggest having an entry in the index referring "background"
to "asynchronously"? It seems to be the more popular term these days.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIt5A8Bcgs9XrR2kYRAvgzAJ9YQtt36T/mZdzR4B2lFoUGme+N3wCeMrx8
UFsZ2hqxR7ExOIPWPjJFbWY=
=kvTV
-----END PGP SIGNATURE-----

Re: & and M-& to run programs asynchronously

[Juri Linkov]

>> There is no term "background" in the existing Emacs documentation,
>> so it is better to use the term "asynchronously" like in the
>> docstring of `shell-command':
>
> Still, may I suggest having an entry in the index referring "background"
> to "asynchronously"? It seems to be the more popular term these days.

Yes, we could do the same as we do with other synonyms that have
a different term outside of Emacs (e.g. "cut/paste" vs "kill/yank")
and to add an entry in the index and maybe an entry in the Glossary.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Daniel Clemente]

This is an old thread.


El jue, jul 31 2008 a les 16:07, Chong Yidong va escriure:
> Juri Linkov <juri@jurta.org> writes:
>
>>> I suppose the next step is to do the same for async-shell-command and
>>> bind it to M-& That's in simple.el. A function can read the user's
>>> input, add "&", and pass the command to shell-command.
>>
>> This can be done with the following patch that adds a new command
>> `async-shell-command'.  I also noticed that code that sets
>> `minibuffer-default-add-shell-commands' could be moved from the
>> interactive spec of `shell-command' to `read-shell-command' so this
>> feature will be available for all functions that read a shell command
>> from the minibuffer (including a new command `async-shell-command').
>
> This is not such a trivial change, since M-& is bound elsewhere in a
> couple of modes.  Let's leave this for after the release.

Now Emacs 23 is already released.

I filed a bug to track what was missing of this new feature:
M-& to run commands asynchronously (async-shell-command)
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4719


-- Daniel

Re: & and M-& to run programs asynchronously

[Daniel Clemente]

  This plan was not completed. The next step would be to add M-& which would work like M-! but asynchronously.

  For a summary of the discussion so far, see the parent thread.

Re: & and M-& to run programs asynchronously

[Juri Linkov]

> This plan was not completed. The next step would be to add M-& which
> would work like M-! but asynchronously.
>
> For a summary of the discussion so far, see the parent thread.

This is already implemented in
http://thread.gmane.org/gmane.emacs.devel/99764/focus=101699
But we have to wait for the next release.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Daniel Clemente]

>> This plan was not completed. The next step would be to add M-& which
>> would work like M-! but asynchronously.
>>
>> For a summary of the discussion so far, see the parent thread.
>
> This is already implemented in
> http://thread.gmane.org/gmane.emacs.devel/99764/focus=101699
> But we have to wait for the next release.


  Sorry, but why do we have to wait to check in features? More than 3 months have passed and I don't know if someone else remembers that this issue was still not resolved.

  This scenario doesn't happen for instance in Bazaar's development, where a tool tracks the patches from the mailing list that are waiting to be merged. See: http://bundlebuggy.aaronbentley.com/

  I look forward to the day when Emacs development focuses on an easy repository and bug tracker so that we can better control issues and patches...


Daniel

Re: & and M-& to run programs asynchronously

[Chong Yidong]

Daniel Clemente <dcl441-bugs@yahoo.com> writes:

>   Sorry, but why do we have to wait to check in features? More than 3
>   months have passed and I don't know if someone else remembers that
>   this issue was still not resolved.

If you're worried about this getting forgotten, file a bug; the report
won't get lost.

Re: & and M-& to run programs asynchronously

[Daniel Clemente]

El jue, sep 11 2008 a les 01:52, Juri Linkov va escriure:
>> This plan was not completed. The next step would be to add M-& which
>> would work like M-! but asynchronously.
>>
>> For a summary of the discussion so far, see the parent thread.
>
> This is already implemented in
> http://thread.gmane.org/gmane.emacs.devel/99764/focus=101699
> But we have to wait for the next release.


  Now we have gone through the miserable bureaucracy of waiting almost 1 year since the patch was written.
  Could the patch for M-&=async-shell-command be finally checked in?

-- Daniel

Re: & and M-& to run programs asynchronously

[Juri Linkov]

> El jue, sep 11 2008 a les 01:52, Juri Linkov va escriure:
>>> This plan was not completed. The next step would be to add M-& which
>>> would work like M-! but asynchronously.
>>>
>>> For a summary of the discussion so far, see the parent thread.
>>
>> This is already implemented in
>> http://thread.gmane.org/gmane.emacs.devel/99764/focus=101699
>> But we have to wait for the next release.
>
> Now we have gone through the miserable bureaucracy of waiting almost
> 1 year since the patch was written.

No, this is not a bureaucracy - we have no enough manpower for the proper
bureaucracy ;-)

> Could the patch for M-&=async-shell-command be finally checked in?

I think `async-shell-command' in
http://thread.gmane.org/gmane.emacs.devel/99764/focus=101699
is just a starting point for implementing more powerful command
that accepts more proposed options (like either to display the output
buffer or not, etc.)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Daniel Clemente]

>> Could the patch for M-&=async-shell-command be finally checked in?
>
> I think `async-shell-command' in
> http://thread.gmane.org/gmane.emacs.devel/99764/focus=101699
> is just a starting point for implementing more powerful command
> that accepts more proposed options (like either to display the output
> buffer or not, etc.)

  Ok; then could this starting point be checked in? It is already useful.

  I think that before trying to extend it, it has to be correctly bound to M-& in the right places and without colliding with other M-&
  Extensions can also wait because there are many and there isn't full consensus ([1]). So better get the base in first.

[1] http://thread.gmane.org/gmane.emacs.devel/99764/focus=100293

Re: & and M-& to run programs asynchronously

[Juri Linkov]

>>> Could the patch for M-&=async-shell-command be finally checked in?
>>
>> I think `async-shell-command' in
>> http://thread.gmane.org/gmane.emacs.devel/99764/focus=101699
>> is just a starting point for implementing more powerful command
>> that accepts more proposed options (like either to display the output
>> buffer or not, etc.)
>
>   Ok; then could this starting point be checked in? It is already useful.
>
>   I think that before trying to extend it, it has to be correctly bound to M-& in the right places and without colliding with other M-&
>   Extensions can also wait because there are many and there isn't full consensus ([1]). So better get the base in first.
>
> [1] http://thread.gmane.org/gmane.emacs.devel/99764/focus=100293

Below is a ready patch submitted for verification before checking in:

Index: lisp/bindings.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.219
diff -c -r1.219 bindings.el
*** lisp/bindings.el	23 Jun 2009 07:39:43 -0000	1.219
--- lisp/bindings.el	30 Jun 2009 00:01:46 -0000
***************
*** 756,761 ****
--- 760,766 ----
  
  (define-key esc-map "!" 'shell-command)
  (define-key esc-map "|" 'shell-command-on-region)
+ (define-key esc-map "&" 'async-shell-command)
  
  (define-key ctl-x-map [right] 'next-buffer)
  (define-key ctl-x-map [C-right] 'next-buffer)

Index: lisp/simple.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/simple.el,v
retrieving revision 1.988
diff -c -r1.988 simple.el
*** lisp/simple.el	13 Jun 2009 18:56:11 -0000	1.988
--- lisp/simple.el	30 Jun 2009 00:02:15 -0000
***************
*** 2054,2059 ****
--- 2054,2076 ----
  	   (or hist 'shell-command-history)
  	   args)))
  
+ (defun async-shell-command (command &optional output-buffer error-buffer)
+   "Execute string COMMAND asynchronously in background.
+ 
+ Like `shell-command' but if COMMAND doesn't end in ampersand, adds `&'
+ surrounded by whitespace and executes the command asynchronously.
+ The output appears in the buffer `*Async Shell Command*'."
+   (interactive
+    (list
+     (read-shell-command "Async shell command: " nil nil
+ 			(and buffer-file-name
+ 			     (file-relative-name buffer-file-name)))
+     current-prefix-arg
+     shell-command-default-error-buffer))
+   (unless (string-match "&[ \t]*\\'" command)
+     (setq command (concat command " &")))
+   (shell-command command output-buffer error-buffer))
+ 
  (defun shell-command (command &optional output-buffer error-buffer)
    "Execute string COMMAND in inferior shell; display output, if any.
  With prefix argument, insert the COMMAND's output at point.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Lennart Borgman]

On Tue, Jun 30, 2009 at 10:16 PM, Stefan
Monnier<monnier@iro.umontreal.ca> wrote:
>> Below is a ready patch submitted for verification before checking in:
>
> As it stands its usefulness is rather dubious: the user could just as
> easily type the extra & at the end.

Would that work on w32?

> Could someone remind me what were
> the arguments for adding it?  What are the expected use-cases and
> planned improvements?
>
>
>        Stefan
>
>
>

Re: & and M-& to run programs asynchronously

[Juri Linkov]

>> Below is a ready patch submitted for verification before checking in:
>
> As it stands its usefulness is rather dubious: the user could just as
> easily type the extra & at the end.  Could someone remind me what were
> the arguments for adding it?  What are the expected use-cases and
> planned improvements?

Sure, in its current state it is useless.  That's why I said
it is just a starting point for adding more options relevant only
for asynchronous commands.  These options include using M-& as an
application launcher that will allow automatic creation of
multiple *Async Shell Command* buffers, deciding whether to
display the output buffer for GUI apps or not, etc.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> As it stands its usefulness is rather dubious: the user could just as
>> easily type the extra & at the end.  Could someone remind me what were
>> the arguments for adding it?  What are the expected use-cases and
>> planned improvements?
>
> Sure, in its current state it is useless.  That's why I said
> it is just a starting point for adding more options relevant only
> for asynchronous commands.  These options include using M-& as an
> application launcher that will allow automatic creation of
> multiple *Async Shell Command* buffers, deciding whether to
> display the output buffer for GUI apps or not, etc.

I agree -- a separate command feels much cleaner to me than insisting
the user type "&" at the end of the command.  The "&" syntax is a nice
_add-on_ hack for people used to using a shell, but it shouldn't be the
primary method of invocation for background apps.

I personally would often like to use emacs to launch GUI apps, rather
than needing to use a shell or search through menus.

In general, the current Emacs support for asynchronous apps seems quite
clumsy.  I usually don't want the "*Async Shell Command*" output buffer,
or at least, don't want to see it unless there's actually some
output... (which there usually isn't).  The current restriction to a
single background app is simply dumb.

Fixing those problems isn't necessarily connected with having a
separate command -- both forms of invocation should benefit -- but the
dedicated command still seems a much nicer interface to me

-Miles

-- 
Philosophy, n. A route of many roads leading from nowhere to nothing.

Re: & and M-& to run programs asynchronously

[Juri Linkov]

> In general, the current Emacs support for asynchronous apps seems quite
> clumsy.  I usually don't want the "*Async Shell Command*" output buffer,
> or at least, don't want to see it unless there's actually some
> output... (which there usually isn't).  The current restriction to a
> single background app is simply dumb.

It seems the best user interface to interactively modify the behavior of
the command before executing it would be a set of keys to toggle a state
variable in the minibuffer in the same way as was recently proposed for
refraining from recording the item in the minibuffer history (instead of
ignoring entries starting with space).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Fernando]

Hello.
I don't know if it's worth to open a new thread, but as this one is
related I'll like to report some problem I've had while testing the
new "&" command  (dired-do-async-shell-command).

If you use it to execute a command that opens a child process then it
will have no effect at all, the parent process will be finished and no
program will be executed. You can reproduce this if you execute &
xdg-open (freedesktop command for opening a file).

dired-do-shell-command does work when you use it to execute xdg-open,
but it will run the program synchronously.

Would it be possible to fix this so that "&" waits for child processes
running asynchronously to finish?

--
Fernando

Re: & and M-& to run programs asynchronously

[Juri Linkov]

> I don't know if it's worth to open a new thread, but as this one is
> related I'll like to report some problem I've had while testing the
> new "&" command  (dired-do-async-shell-command).
>
> If you use it to execute a command that opens a child process then it
> will have no effect at all, the parent process will be finished and no
> program will be executed. You can reproduce this if you execute &
> xdg-open (freedesktop command for opening a file).
>
> dired-do-shell-command does work when you use it to execute xdg-open,
> but it will run the program synchronously.
>
> Would it be possible to fix this so that "&" waits for child processes
> running asynchronously to finish?

I see that running `M-! xdg-open file &' works correctly on KDE,
but fails on Gnome.  Is this an Emacs bug at all?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: & and M-& to run programs asynchronously

[Jan Djärv]

Juri Linkov skrev:
>> I don't know if it's worth to open a new thread, but as this one is
>> related I'll like to report some problem I've had while testing the
>> new "&" command  (dired-do-async-shell-command).
>>
>> If you use it to execute a command that opens a child process then it
>> will have no effect at all, the parent process will be finished and no
>> program will be executed. You can reproduce this if you execute &
>> xdg-open (freedesktop command for opening a file).
>>
>> dired-do-shell-command does work when you use it to execute xdg-open,
>> but it will run the program synchronously.
>>
>> Would it be possible to fix this so that "&" waits for child processes
>> running asynchronously to finish?
> 
> I see that running `M-! xdg-open file &' works correctly on KDE,
> but fails on Gnome.  Is this an Emacs bug at all?
> 

On my system emacs starts a shell in a subprocess that execs xdg-open.
xdg-open starts gnome-open in a subprocess and waits for it to finish.  I 
presume KDE starts kde-open instead. gnome-open then starts the real program 
without waiting for it to finish.

I can see that gnome-open does not close the tty before execing the real 
program, so when the tty goes away (i.e. gnome-open finishes) a SIGHUP is 
sent.  That means the program dies.

kde-open on the other hand does close the controlling tty.

One way to fix this in Emacs would be to keep the tty around as long as there 
are processes that has it open (like ssh does).  But IMHO this is a bug in 
gnome-open.

	Jan D.

Re: & and M-& to run programs asynchronously

[Stefan Monnier]

>>> Below is a ready patch submitted for verification before checking in:
>> As it stands its usefulness is rather dubious: the user could just as
>> easily type the extra & at the end.  Could someone remind me what were
>> the arguments for adding it?  What are the expected use-cases and
>> planned improvements?
> Sure, in its current state it is useless.  That's why I said
> it is just a starting point for adding more options relevant only
> for asynchronous commands.  These options include using M-& as an
> application launcher that will allow automatic creation of
> multiple *Async Shell Command* buffers, deciding whether to
> display the output buffer for GUI apps or not, etc.

OK, thanks.  That makes sense.


        Stefan