From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thorsten Jolitz Newsgroups: gmane.emacs.help Subject: Re: Calling emacsclient Date: Wed, 14 Nov 2012 21:01:15 +0100 Message-ID: <87zk2kuf78.fsf@googlemail.com> References: <87ip9b9zvj.fsf@gmail.com> <878va4nlq7.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1352923287 1153 80.91.229.3 (14 Nov 2012 20:01:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Nov 2012 20:01:27 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Nov 14 21:01:38 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TYj9V-0005ow-Nq for geh-help-gnu-emacs@m.gmane.org; Wed, 14 Nov 2012 21:01:37 +0100 Original-Received: from localhost ([::1]:54544 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYj9M-0003p8-1d for geh-help-gnu-emacs@m.gmane.org; Wed, 14 Nov 2012 15:01:28 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYj9E-0003oA-Fn for help-gnu-emacs@gnu.org; Wed, 14 Nov 2012 15:01:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYj9B-00061Q-DW for help-gnu-emacs@gnu.org; Wed, 14 Nov 2012 15:01:20 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:44417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYj9B-00061J-31 for help-gnu-emacs@gnu.org; Wed, 14 Nov 2012 15:01:17 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TYj9J-0005Zy-4r for help-gnu-emacs@gnu.org; Wed, 14 Nov 2012 21:01:25 +0100 Original-Received: from e178054191.adsl.alicedsl.de ([85.178.54.191]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2012 21:01:25 +0100 Original-Received: from tjolitz by e178054191.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2012 21:01:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 125 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: e178054191.adsl.alicedsl.de User-Agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.0.93 (gnu/linux) Cancel-Lock: sha1:RzAQ5TOcac0nJykUWPWpEIOvRkI= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:87692 Archived-At: William Gardella writes: Hi William, thanks a lot for you help. > Hi again, I had some further notes/thoughts for clarification. > > Thorsten Jolitz writes: > >> I have another problem not yet solved - I want to call an Emacsclient >> with a file to open and some code to evaluate. Using the "-c" and >> "--eval" options in one call gives an error for me, and this seems to be >> in accordance with the manual that says its either the one or the other. >> >> However, if I try two sequential calls instead, it works somehow, but >> not as intended. These two calls directly after another >> >> ,-------------------------- >> | (call 'emacsclient >> | "-c" "my/dir/my-file") >> `-------------------------- >> >> ,--------------------------- >> | (call 'emacsclient >> | "--eval" >> | "(message \"CALL 1\")") >> `--------------------------- >> >> open a new emacs-frame showing a 'my-file' buffer, but in the *Messages* >> buffer there is no CALL 1 message. But when I kill the Emacsclient-frame >> with C-x C-c, CALL 1 is shown as return value in the calling external >> program and now appears in the *Messages* buffer too. It seems the >> second call is waiting for the first call to terminate. > > This is actually expected behavior, by the way. In an interactive emacs > environment such as an emacsclient frame, `standard-output' is the > *Messages* buffer. In a batch arrangement, such as emacsclient --eval, > `standard-output' is the calling shell or program's standard output. So > I'm guessing that your second call actually completes normally, but you > don't see it until you close the frame. Maybe its related to this too: ,------------------------------------------------------ | Apparently there is a problem with running C programs | that use stdout under Emacs: stdout is attached to a | pipe, which is a block device, rather than the | console, which is a character device. Thus, you don't | get your output until the program terminates or there | is enough data to fill the block buffer. `------------------------------------------------------ from: http://lua-users.org/lists/lua-l/2007-04/msg00642.html > There is a syntax for using --eval inside an existing interactive > emacsclient frame. One cannot combine -t and -e. Try emacsclient -te > '(message "boop") and check your *Messages* buffer. I tried that, but the bahaviour of "-e" and "-te" is exactly the same - output appears only after the frame is closed. > What is the Lisp-like program composing these calls, by the way? Is > this scsh or something? Its PicoLisp: http://picolisp.com/5000/!wiki?home here is the doc for call: http://software-lab.de/doc/refC.html#call PicoLisp has a command-line modeled after Vi (modal editing), and I'm writing an Emacs mode for that command-line. That does not only include using Emacs keybindings for editing and navigation on the command-line, but also calling an editor (Vi or Emacs) for editing symbols or PicoLisp source-files. So the PicoLisp philosophy is a bit upside down - you work on the command-line and call an editor when you need one (and close it when done), instead of living inside the editor and controlling external programs via Emacs subprocesses. Emacsclient is the perfect solution for this 'open an editor on demand' philosphy. There is a PicoLisp major mode (picolisp.el) for Emacs and a comint based inferior-picolisp.el (and even a swank/slime implementation) that can be used the usal way - opening a .l (PicoLisp source) file puts it in PicoLisp-mode, and a call to 'run-picolip' starts a PicoLisp process in a dedicated process-buffer from inside Emacs. Then, code in the source buffer can be evaluated and send to the process buffer. What I'm struggling with is that in my use case, PicoLisp calls Emacs not vice versa. So there is an open connection between both programs, probably based on stdin/out, and I would like to use it to do the usual things like ,------------------------------------------------ | C-x C-e picolisp-send-last-sexp | C-c C-e picolisp-send-definition | C-c C-l picolisp-load-file | C-c C-r picolisp-send-region | C-c C-x switch-to-picolisp | C-c M-e picolisp-send-definition-and-go | C-c M-r picolisp-send-region-and-go `------------------------------------------------ but not sending from the source-code buffer in the emacsclient to a process-buffer, but rather sending from the Emacs source-code buffer to the PicoLisp command-line shell, i.e. via stdout back to the calling program ... ... that sits there after calling emacsclient (inside the 'em' function) ,--------------------- | : (em 'edit) | Waiting for Emacs... `--------------------- So I - probably - would need to 1. change stdout from *Messages* to regular stdout 2. flush output immediately after written 3. make output appear in the PicoLisp shell Or maybe I should rather use the existing connection and open an Emacs process-buffer for it - but how do I get a process-object for it? -- cheers, Thorsten