Re: Proposal: emacsclient --readonly

[Michael Mauger]

> 

>>  In the C code, if there are any unrecognized options they will be sent 
> over 
>>  as a -custom option followed by the non-option parameters as -args
> 
> I'm not sure I understand right, but it doesn't sound like it's 
> going
> a direction I like: I'd like to reduce the difference between the
> C-level command line argument vector received by emacsclient and the
> list of strings received by server.el.
> 

Not sure how this is possible because the parameters are not
sent as they are encountered.  Based on the settings the client
programs behavior is altered so I will try to accomplish this as
best as I can.

>>  On the server side, the elisp will call the handler for each -custom 
> option 
>>  and pass the args along with it.
> 
> The --diff and --eval options don't take just one "argument", 
> which is
> why I don't want to hardcode this idea of a "--option ARG" format.
> 


I clearly wasn't very eloquent  last nite, in fact, after reading what I 
wrote, I'm not sure I knew what I meant.  I started to hack at this 
and I think I can describe it with more clarity now:

In the C code, we use getopt_long_only to parse the command 
line args, so I want to make sure that the custom options behave
as the built-in options do, so there is some complexity here.

If an option is encountered that is not recognized, then we will 
parse the argument string to see if it is in the format OPTION=ARG,
if it is, then we send the following "-custom OPTION -arg ARG".
In this case, that is the only option value and parsing continues
with the next comand line arg.  

If the option lacks an equal sign, then the option is sent with
"-custom OPTION", it then scans thru the following arguments 
and any that don't start with a hyphen will be sent as "-arg XXX"
so that there may be many -arg entries following the -custom.

The danger, of course, is that we may associate an arg with an
option because the C program knows nothing about the option
or the number of args it takes.  So the elisp side will have to take
any unused args and treat them as either -file or -eval entries.
There be dragons here.  If the --eval option was specified, the flag
is not sent so the elisp side doesn't know to treat the unused args 
as expressions rather than file names unless there are other non-
option arguments supplied.  This is going to require some addl
info being sent to elisp but it's not a real complication.

Here's an example:

    emacsclient --eval --my-new-option A B C

Sends:
    -... standard entries dispay, dir, env, et al
    -custom my-new-option -arg A -arg B -arg C

If my-new-option requires two args then it consumes A and B.

This leaves C as a unused entry.  Since there are no -file or 
-eval entries we don't know how to handle the unused unless
there is a separate entry to indicate how unused args should
be handled.

The ambiguity can be addressed by specifying the arguments 
as:

    emacsclient --eval C --my-new-option A B
or
    emacsclient --my-new-option A B --eval C

There may be some issues since the options and parameters
are not sent to the elisp code in the same order they are 
specified.  This isn't easy to correct so I expect that some 
custom options may have unintended behavior because the
sequence of file-opens or expression-evaluations may not 
happen in the same order.  

> 
> Refactoring sounds fine.
> 


I hope this clarifies things a bit.  As I said, I've got some of 
the code ready and should wrap it up tonite.  I'll then try to
implement --readonly and --diff to demonstrate how this will
all look.

-- Michael