emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Change in emacsclient behavior


From: Davis Herring
Subject: Re: Change in emacsclient behavior
Date: Tue, 4 Sep 2007 16:08:24 -0700 (PDT)
User-agent: SquirrelMail/1.4.8-6.el3.2lanl

> 1. When invoked without arguments, display the current frame (-c uses the
> current frame, but this could be customizable to display the initial frame
> or any of existing frames).

And if we're on a text link to a host that was previously running only
graphical Emacs?  It seems there that it would be much more useful to
create a new tty frame where emacsclient was run.

Reading the rest of this list, I come to the conclusion that what UI
emacsclient should expose or create and what action it should take should
be entirely decoupled (up to, perhaps, some reasonable default UIs for
certain actions that are beyond the scope of this message).  As a
disclaimer, I am not an expert in old or new emacsclient, or multi-tty in
general.  However, it seems that a clean design for emacsclient can be had
that supports (almost) all uses, from remote or local terminals.  I have
kept Emacs option names where they seemed relevant, but ignored extant
emacsclient convention entirely.  So here goes:

For the UI, emacsclient can:

1. Create and become a tty for Emacs (with at least one frame).
2. Create and raise a graphical frame for Emacs on the current $DISPLAY.
3. Raise an existing graphical frame for Emacs on the current $DISPLAY, or
elsewhere if no such exists.
4. Try to raise an existing frame, or create one if it doesn't exist.
5. Become a pipe for Emacs (which may or may not produce any terminal
output).

2 and 4 should devolve to 1 if there is no suitable $DISPLAY available.

These choices can be expressed as options.  I'd put #4 as the default, and
let --select give #3, --create give #2, -nw give #1, and -batch give #5.

Then there is the question of what to do.  Call the frame newly created or
raised the "target" frame.

1. Do nothing (let the target frame show what it does or likes): no arguments
2. Visit some number of files (which may or may not create additional
frames, depending on `pop-up-frames' and/or --select): file arguments,
possibly with line/column numbers, etc.
3. Evaluate Lisp (in the target frame if not -batch; in some other frame
(TBD) otherwise).  In the case of #5, that Lisp gets `emacsclient-pipe'
bound to a process object representing the pipe to emacsclient.  This
operation is selected by --eval or perhaps -f for a simple function call.

Finally, of course, an emacsclient that does not become a tty or pipe (#2,
#3, #4) may wait or not on some signal from Emacs that editing is done;
whether the command that sends that signal destroys the frames that
emacsclient created (if any) is a user option completely outside the scope
of emacsclient.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.




reply via email to

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