Re: Proposal: emacsclient --readonly

[Michael Mauger]

> From: Stefan Monnier <address@hidden>

> 
> My suggestion is to try and limit the server.el change to
> something like the patch below.
> 
> === 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)))))
> 
> +(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))
> 

So with this structure, how would I implement the --readonly custom
argument?

My guess is that the server-custom-option-function would scan the
incoming list of options for the -nowait entry because that will
determine our exit action.  However, we will leave the entry in place
because it needs the standard processing.  We will then look for the
--readonly entry and record that we want to view files rather than
edit them.  We will then remove the --readonly entry from the list to
allow the remainder of the processing to continue.

We can only record these settings at this point because the files have
not been actually opened yet.  And then we need to attach ourselves to
the server-visit-hook possibly to actually activate the readonly
behavior.  Or we could essentially duplicate the server processing by
consuming all of the arguments and replicating their actions with the
wrinkles we wish to introduce which is obviously not a great solution.

So it looks with the solution may be more flexible but requires global
variables specific to the feature and two hook functions to implement
it. My goal was for a solution the declares the options we want to add
and somewhat automate the parsing and validation of the option value
so that custom options behave as other command line arguments do.  It
then provides a handler function that implements the feature either
globally or on a per-buffer basis.  With this design, features could
be added to emacsclient by loading a library and adding an entry to a
list that defines the syntax and handling.

I have reworked my code to use a single list with option-name, handler
function, and value-predicate.  The result is that we could implement
modules in ELPA that would enhance emacsclient with new options
without requiring the modules to be integrated together into a single
function.  The readonly feature becomes about 10 lines of code; easily
maintained and separate from any other features.

-- Michael