emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]