[occ@cs.bath.ac.uk: emacsclient --eval has slightly counterintuititve behaviour.]

[occ@cs.bath.ac.uk: emacsclient --eval has slightly counterintuititve behaviour.]

[Richard Stallman]

I think this is a bug--emacsclient should at least terminate.  Would
someone like to fix it?

------- Start of forwarded message -------
From: occ <occ@cs.bath.ac.uk>
To: bug-gnu-emacs@gnu.org
Content-Type: text/plain
Date: Thu, 02 Mar 2006 00:39:15 +0000
Mime-Version: 1.0
Subject: emacsclient --eval  has slightly counterintuititve behaviour.

I've noticed something which may be a bug in the  -eval command in the
handling in the emacsclient/server. 

Summary: "emacsclient --eval" never returns if the passed elisp string
is invalid or fails. 

Version:  CVS (as of today) 

Example: 
emacsclient.emacs-snapshot --eval some_invalid_elisp

emacs *Messages* report: 
error in process filter: Symbol's value as variable is void:
some_invalid_elisp

(which is to be expected) 

emacsclient then sits there indefinitely trying to read from the server
socket. 

Expected result: at the very least emacsclient should return, at best
return with an error. 

Is there ever a way for an lisp expression invoked from emacsclient  to
write stuff back to emacsclient?  If not then having --eval -->
- --no-wait in emacsclient would be sufficient to solve the problem. 

(although i think making the server always respond with at least a empty
write when it is invoked without -nowait is the polite thing to do) 

owen 
- -- 
- ---------------------------------------------------------------------
owen cliffe (postgraduate)          Email: occ@cs.bath.ac.uk
Department of Computer Science        Web: http://www.cs.bath.ac.uk/~occ
Univ. Bath, Bath, England BA2 7AY      Tel: (+44) 1225 386183



_______________________________________________
bug-gnu-emacs mailing list
bug-gnu-emacs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

Re: [occ@cs.bath.ac.uk: emacsclient --eval has slightly counterintuititve behaviour.]

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

> I think this is a bug--emacsclient should at least terminate.  Would
> someone like to fix it?

Any error during the parsing and evaluation of the argument will now cause
to send back the error object preceded by "error: " to the client.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [occ@cs.bath.ac.uk: emacsclient --eval has slightly counterintuititve behaviour.]

[Andrea Russo]

Hi,

This is my first attempt at fixing the code, I hope this is not too
heavyweight because of an evaluation of arbitrary code called inside a
condition-case form. It also doesn't take care of signaling emacslient
that an error condition occurred on the server.

I'm not an emacs expert, so this is the best I can do for now.
This at least avoid that emacsclient waits for input on the pipe.

Thanks,
Andrea.

--- orig/lisp/server.el
+++ mod/lisp/server.el
@@ -343,17 +343,17 @@
 	    (if coding-system
 		(setq arg (decode-coding-string arg coding-system)))
 	    (if eval
-		(let ((v (eval (car (read-from-string arg)))))
-		  (when v
-		    (with-temp-buffer
-		      (let ((standard-output (current-buffer)))
-			(pp v)
-			;; Suppress the error rose when the pipe to PROC is closed.
-			(condition-case err
+		(condition-case err
+		    (let ((v (eval (car (read-from-string arg)))))
+		      (when v
+			(with-temp-buffer
+			  (let ((standard-output (current-buffer)))
+			    (pp v)
+			    ;; Suppress the error rose when the pipe to PROC is closed.
 			    (process-send-region proc (point-min) (point-max))
-			  (file-error nil)
-			  (error nil))
-			))))
+			  ))))
+		  (file-error nil)
+		  (error nil))
 	      ;; ARG is a file name.
 	      ;; Collapse multiple slashes to single slashes.
 	      (setq arg (command-line-normalize-file-name arg))

Re: [occ@cs.bath.ac.uk: emacsclient --eval has slightly counterintuititve behaviour.]

[Richard Stallman]

    Any error during the parsing and evaluation of the argument will now cause
    to send back the error object preceded by "error: " to the client.

Thanks.