[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: emacsclient --readonly
From: |
Michael Mauger |
Subject: |
Re: Proposal: emacsclient --readonly |
Date: |
Sun, 24 Mar 2013 09:22:22 -0700 (PDT) |
----- Original Message -----
> From: Stefan Monnier <address@hidden>
>
>> server-custom-option-functions:
> [...]
>> server-custom-option-list nil
>
> How 'bout a `server-custom-option-function' which takes the list of
> arguments and returns a new list of arguments?
>
>
> Stefan
I don't understand your comment--the `server-custom-option-list'
variable is the list of options for parsing; the
`server-custom-option-functions' variable is the list of functions to
handle the options. I 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
entries like the following:
("OPTION" {PRED|t|nil|string-only} HANDLER)
I don't understand what arguments "takes the list of arguments and
returns a new list of arguments" you are referring to? Do you mean
parsing the command line args and removing the ones that it is
processing? I 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.
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?
Thanks, Michael
- Proposal: emacsclient --readonly, michael, 2013/03/13
- Re: Proposal: emacsclient --readonly,
Michael Mauger <=
- Re: Proposal: emacsclient --readonly, Stefan Monnier, 2013/03/25
- Re: Proposal: emacsclient --readonly, Michael Mauger, 2013/03/25
- Re: Proposal: emacsclient --readonly, Stefan Monnier, 2013/03/26
- Re: Proposal: emacsclient --readonly, Michael Mauger, 2013/03/26
- Re: Proposal: emacsclient --readonly, Stefan Monnier, 2013/03/26
- Re: Proposal: emacsclient --readonly, Michael Mauger, 2013/03/27
- Re: Proposal: emacsclient --readonly, Michael Mauger, 2013/03/30