emacsclient proposal

emacsclient proposal

[David Kastrup]

Hi,

I think I would very much like to have an emacsclient process be
exposed to Emacs as an Emacsclient process.  This means for me the
following:

stdin from emacsclient will be available to the process-filter.
process-send-string and process-send-eof will work on the stdout of
emacsclient.

Killing or signaling the emacsclient process will do the appropriate
thing on the other end.

In that manner, I could set

PAGER=emacsclient -f client-pager

and if some command like "man" gets called in a shell, an Emacs window
will open up and Emacs will fill this window with material in
view-mode.

-- 
David Kastrup

Re: emacsclient proposal

[Stefan Monnier]

> I think I would very much like to have an emacsclient process be
> exposed to Emacs as an Emacsclient process.

Based on my memory of the code, it shouldn't be too hard to do.
Basically, define a new arg (not -f because that's used already) and a way
to represent it in the text passed to Emacs, and then have it specify
a function which will receive the process as argument, at which point the
function can freely do I/O with that process.

There might be a few details to get right (maybe just in the form of
documentation) w.r.t handling of the sentinel, filter, and args passed to
the function, but nothing too terrible.


        Stefan

Re: emacsclient proposal

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I think I would very much like to have an emacsclient process be
>> exposed to Emacs as an Emacsclient process.
>
> Based on my memory of the code, it shouldn't be too hard to do.
> Basically, define a new arg (not -f because that's used already)

Uh, -f was a typo.  I really meant --eval in my example.

> and a way to represent it in the text passed to Emacs, and then have
> it specify a function which will receive the process as argument, at
> which point the function can freely do I/O with that process.

Oh, actually the idea was not to have emacsclient tell Emacs that it
wants to get a process.  Rather Emacs should have a way to tell
emacsserver through the socket "here is something (including eof) for
stdout", "see if you can get anything on stdin for me and send it over
once you do", "somebody thinks you deserve the following signal"
(actually, Emacs might choose to just send the signal by itself, but
if we ever allow non-local emacsclient sessions, we'll need to have
emacsclient cater for the delivery itself)".

The creation of a pseudo-process would be initiated by the command
called with --eval.  Something like "get-emacsclient-process" or so.

> There might be a few details to get right (maybe just in the form of
> documentation) w.r.t handling of the sentinel, filter, and args
> passed to the function, but nothing too terrible.

Wouldn't it be fun to be able to put arbitrary Emacs-controlled
stages/popups into a pipe?

-- 
David Kastrup

Re: emacsclient proposal

[dhruva]

Hi,

On 7/19/07, David Kastrup <dak@gnu.org> wrote:
>
> The creation of a pseudo-process would be initiated by the command
> called with --eval.  Something like "get-emacsclient-process" or so.

In a typical situation, there could be multiple emacsclient instances
connected to the emacs server. Emacs will have to have a method to
allow the selection of the emacs client it would like to do IO with.
If the user will have to decide/select, we need to have some user
friendly names assigned to each of the clients or some other
mechanism. Using the command line arguments of the emacsclient would
not work as multiple instances could have the same command line args!
 Anyway, this is the first thought that came to my mind...

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

--eval (was: emacsclient proposal)

[Juri Linkov]

> Uh, -f was a typo.  I really meant --eval in my example.

BTW, a pity that Emacs doesn't provide a short option for the `--eval'
command line argument!

By analogy with `--funcall' that have the corresponding `-f',
the short option for `--eval' and `--execute' would be `-e'.

Even though startup.el currently treats `-e' as a shorthand of `-funcall',
it seems that such use of `-e' is obsolete and we are free to reassign it
to `--eval' and `--execute' because the manual doesn't document it:

Index: lisp/startup.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/startup.el,v
retrieving revision 1.440
diff -c -r1.440 startup.el
*** lisp/startup.el	3 Jul 2007 02:54:42 -0000	1.440
--- lisp/startup.el	21 Jul 2007 18:30:09 -0000
***************
*** 1834,1846 ****
  
                  ((member argi '("-f"	; what the manual claims
                                  "-funcall"
!                                 "-e"))  ; what the source used to say
                   (setq tem (intern (or argval (pop command-line-args-left))))
                   (if (commandp tem)
                       (command-execute tem)
                     (funcall tem)))
  
!                 ((member argi '("-eval" "-execute"))
                   (eval (read (or argval (pop command-line-args-left)))))
  
                  ((member argi '("-L" "-directory"))
--- 1874,1886 ----
  
                  ((member argi '("-f"	; what the manual claims
                                  "-funcall"
!                                 ))
                   (setq tem (intern (or argval (pop command-line-args-left))))
                   (if (commandp tem)
                       (command-execute tem)
                     (funcall tem)))
  
!                 ((member argi '("-e" "-eval" "-execute"))
                   (eval (read (or argval (pop command-line-args-left)))))
  
                  ((member argi '("-L" "-directory"))

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

Re: --eval

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> Uh, -f was a typo.  I really meant --eval in my example.
>
> BTW, a pity that Emacs doesn't provide a short option for the `--eval'
> command line argument!
>
> By analogy with `--funcall' that have the corresponding `-f',
> the short option for `--eval' and `--execute' would be `-e'.
>
> Even though startup.el currently treats `-e' as a shorthand of `-funcall',
> it seems that such use of `-e' is obsolete and we are free to reassign it
> to `--eval' and `--execute' because the manual doesn't document it:

Deprecating -e is ok with me, but a potentially dangerous command may
well be spelled explicitly.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: --eval

[Jeremy Maitin-Shepard]

David Kastrup <dak@gnu.org> writes:

> Juri Linkov <juri@jurta.org> writes:
>>> Uh, -f was a typo.  I really meant --eval in my example.
>> 
>> BTW, a pity that Emacs doesn't provide a short option for the `--eval'
>> command line argument!
>> 
>> By analogy with `--funcall' that have the corresponding `-f',
>> the short option for `--eval' and `--execute' would be `-e'.
>> 
>> Even though startup.el currently treats `-e' as a shorthand of `-funcall',
>> it seems that such use of `-e' is obsolete and we are free to reassign it
>> to `--eval' and `--execute' because the manual doesn't document it:

> Deprecating -e is ok with me, but a potentially dangerous command may
> well be spelled explicitly.

Potentially dangerous?  Evaluating is hardly something that is
safe-guarded anywhere in emacs.  Furthermore, unlike a key binding that
might accidentally be hit and do something unexpected, it is highly
unlikely to perform some harmful action when something completely
different was intended.

Most importantly, if -e is typed by mistake, the argument will almost
certain not be a valid lisp expression, and even if it is, it almost
certainly won't be a lisp expression that results in a function call.

-- 
Jeremy Maitin-Shepard

Re: --eval

[Richard Stallman]

    Deprecating -e is ok with me, but a potentially dangerous command may
    well be spelled explicitly.

I agree.  We do not need an abbreviation for --eval.