Feature request: Expose system `exec` as a built-in elisp function

Feature request: Expose system `exec` as a built-in elisp function

[Andrew Pennebaker]

Could the next version of Emacs / elisp expose `exec` as a built-in elisp
function?

The Unix `exec` semantic is useful for Cask and other Emacs-related
programs, but is currently not accessible via elisp. If it were, elisp
programs could, for example, begin an Emacs editing session even though the
elisp program itself was originally run using emacs.

-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: Feature request: Expose system `exec` as a built-in elisp function

[Barry Margolin]

In article <mailman.7022.1407855404.1147.help-gnu-emacs@gnu.org>,
 Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:

> Could the next version of Emacs / elisp expose `exec` as a built-in elisp
> function?

Isn't this pretty much what start-process does?

> 
> The Unix `exec` semantic is useful for Cask and other Emacs-related
> programs, but is currently not accessible via elisp. If it were, elisp
> programs could, for example, begin an Emacs editing session even though the
> elisp program itself was originally run using emacs.

I can't figure out what you're talking about here.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Feature request: Expose system `exec` as a built-in elisp function

[Andrew Pennebaker]

That's what I thought, at first. exec has the additional semantic that it
replaces the current process with the system call, so it's more efficient
for certain tasks.


On Wed, Aug 13, 2014 at 10:29 AM, Barry Margolin <barmar@alum.mit.edu>
wrote:

> In article <mailman.7022.1407855404.1147.help-gnu-emacs@gnu.org>,
>  Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
>
> > Could the next version of Emacs / elisp expose `exec` as a built-in elisp
> > function?
>
> Isn't this pretty much what start-process does?
>
> >
> > The Unix `exec` semantic is useful for Cask and other Emacs-related
> > programs, but is currently not accessible via elisp. If it were, elisp
> > programs could, for example, begin an Emacs editing session even though
> the
> > elisp program itself was originally run using emacs.
>
> I can't figure out what you're talking about here.
>
> --
> Barry Margolin, barmar@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
>



-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: Feature request: Expose system `exec` as a built-in elisp function

[Emanuel Berg]

Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:

> That's what I thought, at first. exec has the
> additional semantic that it replaces the current
> process with the system call, so it's more efficient
> for certain tasks.

Yes, exec (man "exec") does this. It accepts an
argument for what program to execute, and then a list
of arguments (the argv) to be inputed that program.

It is usually used with fork. One process devides itself
with fork(), which returns twice (magic!), and from the
return values the child process can be identified;
then, the child uses exec to fill itself with software
so it can do something productive.

So as for this method and setting (which may be
different from yours) it is not a matter of efficiency,
it is rather that without exec, often there isn't
anything for the child to do. (You probably already
know all this.)

So if you want to replace the current process, can't
you just have the current process execute whatever code
you had in mind for exec?

-- 
underground experts united

Re: Feature request: Expose system `exec` as a built-in elisp function

[Andrew Pennebaker]

One example of the worthiness of exec is cask, an Emacs package manager
that sometimes wants to fork out to an emacs instance, for editing text
files.


On Wed, Aug 13, 2014 at 1:45 PM, Emanuel Berg <embe8573@student.uu.se>
wrote:

> Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:
>
> > That's what I thought, at first. exec has the
> > additional semantic that it replaces the current
> > process with the system call, so it's more efficient
> > for certain tasks.
>
> Yes, exec (man "exec") does this. It accepts an
> argument for what program to execute, and then a list
> of arguments (the argv) to be inputed that program.
>
> It is usually used with fork. One process devides itself
> with fork(), which returns twice (magic!), and from the
> return values the child process can be identified;
> then, the child uses exec to fill itself with software
> so it can do something productive.
>
> So as for this method and setting (which may be
> different from yours) it is not a matter of efficiency,
> it is rather that without exec, often there isn't
> anything for the child to do. (You probably already
> know all this.)
>
> So if you want to replace the current process, can't
> you just have the current process execute whatever code
> you had in mind for exec?
>
> --
> underground experts united
>



-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: Feature request: Expose system `exec` as a built-in elisp function

[Emanuel Berg]

Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:

> One example of the worthiness of exec is cask, an
> Emacs package manager that sometimes wants to fork
> out to an emacs instance, for editing text files.

It seems to me that either you do the job within the
process, or you start a new process to do it.

Are you saying, you want to start a new process, then
have the old process replaced by that process?

If so, why?

-- 
underground experts united

Re: Feature request: Expose system `exec` as a built-in elisp function

[Barry Margolin]

In article <mailman.7068.1407955728.1147.help-gnu-emacs@gnu.org>,
 Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:

> One example of the worthiness of exec is cask, an Emacs package manager
> that sometimes wants to fork out to an emacs instance, for editing text
> files.

I'm not familiar with cask, but usually if you run something within 
Emacs, and it wants you to edit something, you set EDITOR=emacsclient so 
that it goes back to the original Emacs instance. You don't need to 
start a new Emacs instance.

And that still doesn't explain why you would want to kill the original 
Emacs instance when running cask.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Feature request: Expose system `exec` as a built-in elisp function

[Andrew Pennebaker]

Eh, what if you don't want the second emacs call to use the same emacs
configuration, etc. etc. as the parent emacs process?

Feel free to ask the cask project for more details:

https://github.com/cask/cask



On Wed, Aug 13, 2014 at 3:36 PM, Barry Margolin <barmar@alum.mit.edu> wrote:

> In article <mailman.7068.1407955728.1147.help-gnu-emacs@gnu.org>,
>  Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
>
> > One example of the worthiness of exec is cask, an Emacs package manager
> > that sometimes wants to fork out to an emacs instance, for editing text
> > files.
>
> I'm not familiar with cask, but usually if you run something within
> Emacs, and it wants you to edit something, you set EDITOR=emacsclient so
> that it goes back to the original Emacs instance. You don't need to
> start a new Emacs instance.
>
> And that still doesn't explain why you would want to kill the original
> Emacs instance when running cask.
>
> --
> Barry Margolin, barmar@alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
>



-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: Feature request: Expose system `exec` as a built-in elisp function

[Emanuel Berg]

Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:

> Eh, what if you don't want the second emacs call to
> use the same emacs configuration, etc. etc. as the
> parent emacs process?
>
> Feel free to ask the cask project for more details

Yeah, this is too specific an issue for me to
contribute.

Did you, in your words, expose the system exec, but not
as a built-in but just as code? Did you succeed with
that? If so, do you mind showing us?

What happens if you put a C function in the emacs C
which does exec, recompile, and then bind that to a
command? Would that work? Sounds kind of dangerous, but
you shouldn't be afraid of your computer, of course.

-- 
underground experts united

Re: Feature request: Expose system `exec` as a built-in elisp function

[Andrew Pennebaker]

I am kind of afraid, actually. A simple M-x shell C-x C-c is often enough
to kernel panic Mac OS X, depending on various versions.


On Wed, Aug 13, 2014 at 5:16 PM, Emanuel Berg <embe8573@student.uu.se>
wrote:

> Andrew Pennebaker <andrew.pennebaker@gmail.com> writes:
>
> > Eh, what if you don't want the second emacs call to
> > use the same emacs configuration, etc. etc. as the
> > parent emacs process?
> >
> > Feel free to ask the cask project for more details
>
> Yeah, this is too specific an issue for me to
> contribute.
>
> Did you, in your words, expose the system exec, but not
> as a built-in but just as code? Did you succeed with
> that? If so, do you mind showing us?
>
> What happens if you put a C function in the emacs C
> which does exec, recompile, and then bind that to a
> command? Would that work? Sounds kind of dangerous, but
> you shouldn't be afraid of your computer, of course.
>
> --
> underground experts united
>



-- 
Cheers,

Andrew Pennebaker
www.yellosoft.us

Re: Feature request: Expose system `exec` as a built-in elisp function

[Kevin Rodgers]

On 8/13/14 3:42 PM, Andrew Pennebaker wrote:
> Eh, what if you don't want the second emacs call to use the same emacs
> configuration, etc. etc. as the parent emacs process?

Pass -Q on the command line.  Here's what I use to fork a new instance via `M-x
run-emacs RET':

(defun run-emacs (command)
   "Run the Emacs COMMAND in the background via `shell-command'."
   (interactive
    (let ((program (expand-file-name invocation-name invocation-directory)))
      (list (read-string "Emacs command: "
			(cons (concat program
				      " "
				      (if (cdr command-line-args)
					  (mapconcat 'shell-quote-argument
						     (cdr command-line-args)
						     " ")
					"-Q")
				      " &")
			      (1+ (length program)))))))
   (shell-command command))

> Feel free to ask the cask project for more details:
>
> https://github.com/cask/cask
>
>
>
> On Wed, Aug 13, 2014 at 3:36 PM, Barry Margolin <barmar@alum.mit.edu> wrote:
>
>> In article <mailman.7068.1407955728.1147.help-gnu-emacs@gnu.org>,
>>   Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:
>>
>>> One example of the worthiness of exec is cask, an Emacs package manager
>>> that sometimes wants to fork out to an emacs instance, for editing text
>>> files.
>>
>> I'm not familiar with cask, but usually if you run something within
>> Emacs, and it wants you to edit something, you set EDITOR=emacsclient so
>> that it goes back to the original Emacs instance. You don't need to
>> start a new Emacs instance.
>>
>> And that still doesn't explain why you would want to kill the original
>> Emacs instance when running cask.
>>
>> --
>> Barry Margolin, barmar@alum.mit.edu
>> Arlington, MA
>> *** PLEASE post questions in newsgroups, not directly to me ***

-- 
Kevin Rodgers
Denver, Colorado, USA

Re: Feature request: Expose system `exec` as a built-in elisp function

[Barry Margolin]

In article <mailman.7080.1407966184.1147.help-gnu-emacs@gnu.org>,
 Andrew Pennebaker <andrew.pennebaker@gmail.com> wrote:

> Eh, what if you don't want the second emacs call to use the same emacs
> configuration, etc. etc. as the parent emacs process?

I'm not sure why you'd want different Emacs configuration just for that 
one task (couldn't you just put that buffer in an appropriate major 
mode?), but to each his own. 

But you still haven't answered: why should editing the cask files in a 
new Emacs instance require replacing the original Emacs instance, 
instead of running both of them concurrently? This "exec" operation will 
need to perform all the actions done during kill-emacs, like asking 
about saving modified buffers, killing running processes, etc.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Re: Feature request: Expose system `exec` as a built-in elisp function

[Emanuel Berg]

Barry Margolin <barmar@alum.mit.edu> writes:

> But you still haven't answered: why should editing
> the cask files in a new Emacs instance require
> replacing the original Emacs instance, instead of
> running both of them concurrently? This "exec"
> operation will need to perform all the actions done
> during kill-emacs, like asking about saving modified
> buffers, killing running processes, etc.

Indeed, why would anyone like to kill Emacs? It is
inconceivable :)

-- 
underground experts united