Re: Proposal: emacsclient --readonly

[Michael Mauger <michael@mauger.com>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>

>
>>  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.
> 
> Hmm... why do we care about -nowait?
> 

If there is an emacsclient waiting for us to finish, then we have to call
server-buffer-done.

> But I think your design is too narrowly constrained by the needs you see
> now.  I think we should aim for a design that could at least accommodate
> some of the features currently hard-coded such as --eval.
> 
> Ideally it should also accommodate something like "--diff FILE1 FILE2"
> which would call `diff' on the two files and might even be made to
> accept "--diff FILE1 FILE2 FILE3" to do a 3-way merge.
> 

 Okay at least we're sorta on the same page.  I had been thinking about
--diff at one point and the issues got very messy fast.  So here's my
thinking, let me know if you think I should continue:

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

On the server side, the elisp will call the handler for each -custom option 
and pass the args along with it.  The handler can pull off the args it needs.  
If there are any arguments left over, then they will be passed either to 
--eval or treated as files.

The other required change will be to break out some of the file processing
so that the logic can be reused in custom options. 

* file-name generation

* visit a file

This will make the change more complex but won't really alter the 
behavior, just refactor it so it's more useful to custom options.

I should have a prototype in a day or two, unless you think I'm still 
missing the mark.

-- Michael