Suggested change in net/browse-url.el

Suggested change in net/browse-url.el

[David Kastrup]

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


I find it a nuisance that
a) if a generic browser forks and detaches itself from the controlling
tty, Emacs chooses to kill the process group, stopping a browser
client from starting up.

b) If my browser has been started by Emacs, it will get killed when
Emacs is exited.

Personally, I am using firefox and browse-url-generic, and so my
change looks like the following:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Start generic browser without keeping control --]
[-- Type: text/x-patch, Size: 528 bytes --]

--- browse-url.el.~1.34.~	2004-03-10 03:16:38.000000000 +0100
+++ browse-url.el	2004-04-01 19:20:37.000000000 +0200
@@ -1352,8 +1352,8 @@
   (interactive (browse-url-interactive-arg "URL: "))
   (if (not browse-url-generic-program)
     (error "No browser defined (`browse-url-generic-program')"))
-  (apply 'start-process (concat browse-url-generic-program url) nil
-	 browse-url-generic-program
+  (apply 'call-process browse-url-generic-program nil
+	 0 nil
 	 (append browse-url-generic-args (list url))))
 
 ;;;###autoload

[-- Attachment #3: Type: text/plain, Size: 256 bytes --]


Anybody mind if I check it in?  People using other browsers might
consider similar things.  Point b) will still affect them, even if the
specific Problem of starting the browser in the first place works.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Suggested change in net/browse-url.el

[Richard Stallman]

       (if (not browse-url-generic-program)
	 (error "No browser defined (`browse-url-generic-program')"))
    -  (apply 'start-process (concat browse-url-generic-program url) nil
    -	 browse-url-generic-program
    +  (apply 'call-process browse-url-generic-program nil
    +	 0 nil
	     (append browse-url-generic-args (list url))))

This change will always run the browser synchronously.
It might have quite negative effects.
Is this change ok for all the common browsers?

Re: Suggested change in net/browse-url.el

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>        (if (not browse-url-generic-program)
> 	 (error "No browser defined (`browse-url-generic-program')"))
>     -  (apply 'start-process (concat browse-url-generic-program url) nil
>     -	 browse-url-generic-program
>     +  (apply 'call-process browse-url-generic-program nil
>     +	 0 nil
> 	     (append browse-url-generic-args (list url))))
> 
> This change will always run the browser synchronously.

No, it won't.

call-process is a built-in function.
(call-process PROGRAM &optional INFILE BUFFER DISPLAY &rest ARGS)

Call PROGRAM synchronously in separate process.
The remaining arguments are optional.
The program's input comes from file INFILE (nil means `/dev/null').
Insert output in BUFFER before point; t means current buffer;
 nil for BUFFER means discard it; 0 means discard and don't wait.

[...]

Since I use 0 here, the output of calling the process is discarded
and Emacs does _not_ wait.

In fact, this way of using call-process is the _only_ way to start a
process in the background without getting an associated process object
within Emacs.  It is a bit confusing that the API for starting a
particularly asynchronous kind of process is hidden in the function
used normally for starting synchronous processes, but that's not my
fault.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Suggested change in net/browse-url.el

[Richard Stallman]

    Since I use 0 here, the output of calling the process is discarded
    and Emacs does _not_ wait.

You're right.  Sorry for not noticing that.

    In fact, this way of using call-process is the _only_ way to start a
    process in the background without getting an associated process object
    within Emacs.  It is a bit confusing that the API for starting a
    particularly asynchronous kind of process is hidden in the function
    used normally for starting synchronous processes,

Good point.  We could add a new function for this: fork-process.  What
do people think of that?

Re: Suggested change in net/browse-url.el

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Since I use 0 here, the output of calling the process is discarded
>     and Emacs does _not_ wait.
> 
> You're right.  Sorry for not noticing that.
> 
>     In fact, this way of using call-process is the _only_ way to start a
>     process in the background without getting an associated process object
>     within Emacs.  It is a bit confusing that the API for starting a
>     particularly asynchronous kind of process is hidden in the function
>     used normally for starting synchronous processes,
> 
> Good point.  We could add a new function for this: fork-process.  What
> do people think of that?

It would be ok to add it (e.g. in subr.el), but fork-process would be
a mis-leading name for it IMO -- fork means that you get two identical
processes (i.e.  two emacs processes running).

I think call-process-nowait would be better (we already have an analogy
with open-network-stream-nowait).  It would simply be a macro which calls
call-process with 0 BUFFER argument -- but with a specific doc string.

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

Re: Suggested change in net/browse-url.el

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> >     Since I use 0 here, the output of calling the process is discarded
> >     and Emacs does _not_ wait.
> > 
> > You're right.  Sorry for not noticing that.
> > 
> >     In fact, this way of using call-process is the _only_ way to start a
> >     process in the background without getting an associated process object
> >     within Emacs.  It is a bit confusing that the API for starting a
> >     particularly asynchronous kind of process is hidden in the function
> >     used normally for starting synchronous processes,
> > 
> > Good point.  We could add a new function for this: fork-process.  What
> > do people think of that?
> 
> It would be ok to add it (e.g. in subr.el), but fork-process would
> be a mis-leading name for it IMO -- fork means that you get two
> identical processes (i.e.  two emacs processes running).
> 
> I think call-process-nowait would be better (we already have an
> analogy with open-network-stream-nowait).  It would simply be a
> macro which calls call-process with 0 BUFFER argument -- but with a
> specific doc string.

That sounds like a reasonably good way to make that functionality
more visible.

Maybe we would also need other system calls for more functionality:
the lack of job control (putting a program into background after
having started it in the foreground) in eshell might point to that.

But the addition under this name and functionality is nothing that
would declare a can of worms like that open.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum