some dired hints should be background jobs

some dired hints should be background jobs

[Luc Teirlinck]

Dan Jacobson wrote:

    idea, in dired with the cursor on a .pdf file, when we hit ! we get
    ! on man.pdf: [xpdf]
    [by the way, I just copy-and-pasted that line from the minibuffer
    prompt into this message and can't edit it one bit!]
    OK, but better a better default would be running xpdf in the
    background, for which the user has to type "xpdf * &" which BTW
    creates an distracting Async window. Yes, all that can be customized
    on one's own.

The `v' command (in dired) currently will run xpdf and friends in the
foreground, making it impossible to continue using emacs without
killing the xpdf job.  I agree that background would be better.
Changing the default of ! to run background jobs seems trivial, but
one would be stuck with the Async window popping up, which I agree is
distracting.  I also believe it is usually useless.  If one
inadvertently kills the useless buffer, the background job is gone
too.  I myself have M-RETURN bound (in dired) to a command that will
run xpdf and friends in the background, without any Async window
appearing.  A separate window (or frame) is created if necessary to
display output generated by the process, such as error messages and
the like, but only if necessary.  (Usually it is not.)  If people
would agree that this would be a good idea, I could send code for a
command that would either replace the `v' binding or would have a new
binding, say M-RETURN or whatever.  I could not just use my own
current code literally, since it would have to be stripped of personal
idiosyncrasies, but I do not believe that would be difficult to do.

Sincerely,

Luc.

Re: some dired hints should be background jobs

[John Wiegley]

>>>>> Dan Jacobson wrote:

> idea, in dired with the cursor on a .pdf file, when we hit ! we get
> ! on man.pdf: [xpdf] [by the way, I just copy-and-pasted that line
> from the minibuffer prompt into this message and can't edit it one
> bit!]  OK, but better a better default would be running xpdf in the
> background, for which the user has to type "xpdf * &" which BTW
> creates an distracting Async window. Yes, all that can be
> customized on one's own.

Does "&" do anything on Windows?  What should happen then?

John

Re: some dired hints should be background jobs

[Luc Teirlinck]

John Wiegley wrote:

   Does "&" do anything on Windows?  What should happen then?

I know so little about MS Windows (I use GNU/Linux) that I do not
really understand the above.  Do you mean we could not make "xpdf * &"
the default because MS Windows does not understand & and hence it
would not be portable?  Does MS Windows have a notion of job control?
It must have a notion of asynchronous command since it is a windowing
system.

Sincerely,

Luc.

Re: some dired hints should be background jobs

[John Wiegley]

>>>>> Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I know so little about MS Windows (I use GNU/Linux) that I do not
> really understand the above.  Do you mean we could not make "xpdf *
> &" the default because MS Windows does not understand & and hence
> it would not be portable?  Does MS Windows have a notion of job
> control?  It must have a notion of asynchronous command since it is
> a windowing system.

Yep, that's exactly what I mean.  On some Windows shells you can use
"start", but not all.  In fact, I don't believe there is any common
way of backgrounding a job that gets run via shell invocation.

This could mean that "&" is just a UNIX(ish) thing.

John

Re: some dired hints should be background jobs

[Luc Teirlinck]

John Wiegley wrote:

   Yep, that's exactly what I mean.  On some Windows shells you can use
   "start", but not all.  In fact, I don't believe there is any common
   way of backgrounding a job that gets run via shell invocation.

   This could mean that "&" is just a UNIX(ish) thing.

As long as MS Windows would understand the Elisp function
`start-process' and would also understand Elisp's process filter and
sentinel machinery, the command that I have privately bound to
M-RETURN in dired should work on MS windows.  (That is, launch an
asynchronous process.)  Again, I could rewrite that command to be
suitable for inclusion in emacs, if there were interest in that.  For
GNU/Linux and UNIX users the only advantage over "xpdf * &" would be
that you only get an Async buffer if there is actual output and that,
if so, you can kill that buffer without killing the process.  I
personally wrote the command because I got fed up with these empty
Async buffers popping up, but I do not know whether that necessarily
annoys other people as much as it does me.

Sincerely,

Luc.

Re: some dired hints should be background jobs

[Luc Teirlinck]

To avoid confusion, the command I was talking about in my previous
postings could not possibly be used as a default for ! in dired-x,
since it would be an Elisp command, not a shell command.  I do not
view the problem as being about what the correct default for ! in
dired-x should be, but instead about what the most convenient (and
portable) way to launch programs like xpdf and friends, in the
background, from dired should be.  As such, I am thinking of either
changing dired's `v' binding to launch the commands asynchronously
instead of synchronously, or of introducing a separate binding, say
M-RETURN, for the asynchronous version of the current `v'.

Sincerely,

Luc.

Re: some dired hints should be background jobs

[Eli Zaretskii]

> From: John Wiegley <johnw@gnu.org>
> Date: Sun, 02 Mar 2003 17:00:01 -0700
> 
> > I know so little about MS Windows (I use GNU/Linux) that I do not
> > really understand the above.  Do you mean we could not make "xpdf *
> > &" the default because MS Windows does not understand & and hence
> > it would not be portable?  Does MS Windows have a notion of job
> > control?  It must have a notion of asynchronous command since it is
> > a windowing system.
> 
> Yep, that's exactly what I mean.  On some Windows shells you can use
> "start", but not all.

Which ones don't support `start'?  AFAIK, all of them do.

> In fact, I don't believe there is any common
> way of backgrounding a job that gets run via shell invocation.

Actually, I think this is the default on Windows: a GUI program
always opens its own window, and the shell that invoked it doesn't
wit for it.  If not, you could use `start'.

> This could mean that "&" is just a UNIX(ish) thing.

That's true in the sense that the "&" syntax is not understood by
stock Windows shells.