[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: emacsclient --readonly
From: |
Stefan Monnier |
Subject: |
Re: Proposal: emacsclient --readonly |
Date: |
Tue, 26 Mar 2013 09:10:31 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
> So with this structure, how would I implement the --readonly custom
> argument?
Good question.
> 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?
> 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.
Right, we check (equal "--readonly" (car args)) and if non-nil, we (pop
args) and somehow register the "put in read-only mode" somewhere.
> 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.
Right, we don't want to go there.
> 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.
Obviously, my proposal is incomplete indeed because it does not address
the need to "register the `put in read-only mode' somewhere".
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.
Stefan
- Proposal: emacsclient --readonly, michael, 2013/03/13
- Re: Proposal: emacsclient --readonly, Michael Mauger, 2013/03/24
- Re: Proposal: emacsclient --readonly, Stefan Monnier, 2013/03/25
- Re: Proposal: emacsclient --readonly, Michael Mauger, 2013/03/25
- Re: Proposal: emacsclient --readonly,
Stefan Monnier <=
- 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