From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Proposal: emacsclient --readonly Date: Mon, 25 Mar 2013 09:15:11 -0400 Message-ID: References: <87zjxtq304.fsf@michael-laptop.hsd1.ma.comcast.net> <1364142142.92134.YahooMailNeo@web160904.mail.bf1.yahoo.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1364217325 17196 80.91.229.3 (25 Mar 2013 13:15:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Mar 2013 13:15:25 +0000 (UTC) Cc: "emacs-devel@gnu.org" To: Michael Mauger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 25 14:15:48 2013 Return-path: Envelope-to: ged-emacs-devel@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 1UK7Fb-00050o-H8 for ged-emacs-devel@m.gmane.org; Mon, 25 Mar 2013 14:15:47 +0100 Original-Received: from localhost ([::1]:57160 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UK7FD-0003C5-Mj for ged-emacs-devel@m.gmane.org; Mon, 25 Mar 2013 09:15:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UK7F9-00038n-5h for emacs-devel@gnu.org; Mon, 25 Mar 2013 09:15:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UK7F2-0005Iq-Dd for emacs-devel@gnu.org; Mon, 25 Mar 2013 09:15:19 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:27296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UK7F2-0005Il-9M for emacs-devel@gnu.org; Mon, 25 Mar 2013 09:15:12 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFFxLSu/2dsb2JhbAA7Cbs1g1kXc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2NFgSDcAOkeoFegxOBSw X-IPAS-Result: Av8EABK/CFFFxLSu/2dsb2JhbAA7Cbs1g1kXc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2NFgSDcAOkeoFegxOBSw X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="5706215" Original-Received: from 69-196-180-174.dsl.teksavvy.com (HELO pastel.home) ([69.196.180.174]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 25 Mar 2013 09:15:09 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 34EFD678E2; Mon, 25 Mar 2013 09:15:11 -0400 (EDT) In-Reply-To: <1364142142.92134.YahooMailNeo@web160904.mail.bf1.yahoo.com> (Michael Mauger's message of "Sun, 24 Mar 2013 09:22:22 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:158126 Archived-At: > I don't understand your comment--the `server-custom-option-list'=A0 > variable is the list=A0of options for parsing; the=A0 > `server-custom-option-functions' variable is the list=A0of functions to=A0 > handle the options. =A0I can certainly see how we can merge these two > but I'm still confused by your comment. > If we were to merge the variables, we could end up with a list with=A0 > entries like=A0the following: > =A0 =A0("OPTION" {PRED|t|nil|string-only} HANDLER) My proposal is that you don't declare which function handles which argument. Just use a single server-custom-option-function which is called regardless of which arguments were received and can do anything it likes with them. > I don't understand what arguments "takes the list of=A0arguments and=A0 > returns a new list of arguments" you are referring to? =A0Do you mean > parsing the command line args and removing the ones that it is=A0 > processing? Yes. > =A0I had looked at that a little, but figured I'd let the parsing > be done in C in emacsclient and just forward the unrecognized to lisp. Hmm... I don't understand what you're saying here. I'm only talking about the server.el side, and AFAICT you also were only talking about the server.el side, since the client side does not have access to Elisp customizations. But yes, clearly the C side would do the parsing it does now, except that it would additionally pass through any unrecognized argument. > But even if we assemble the custom args into a list and try to handle > them in lisp, how does that simplify the lisp side of the fence? The server.el code already turns the string received from emacsclient into a list of strings. My suggestion is to try and limit the server.el change to something like the patch below. Stefan =3D=3D=3D modified file 'lisp/server.el' --- lisp/server.el 2013-02-13 04:31:09 +0000 +++ lisp/server.el 2013-03-25 13:07:44 +0000 @@ -909,6 +909,12 @@ (process-put proc 'continuation nil) (if continuation (ignore-errors (funcall continuation))))) =20 +(defvar server-custom-option-function #'identity + "Function to process additional emacsclient arguments. +The function is called with a single argument (a list of args received +from emacsclient) and returns the list of args left to process. +The easiest way to modify this variable is through `add-function'.") + (cl-defun server-process-filter (proc string) "Process a request from the server to edit some files. PROC is the server process. STRING consists of a sequence of @@ -1067,7 +1076,8 @@ (setq string (substring string (match-end 0))) (setq args-left (mapcar 'server-unquote-arg (split-string request " " t))) - (while args-left + (while (setq arg-left (funcall server-custom-option-function + args-left)) (pcase (pop args-left) ;; -version CLIENT-VERSION: obsolete at birth. (`"-version" (pop args-left))