[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Change in emacsclient behavior
From: |
Richard Stallman |
Subject: |
Re: Change in emacsclient behavior |
Date: |
Wed, 05 Sep 2007 16:02:44 -0400 |
> 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.
I don't think so. The point of emacsclient is to edit a file in your
existing Emacs. There is no reason why the way to display that file
should depend on where emacsclient was run.
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).
These all seem useful in principle. 5 seems hard and I doubt it is
worth implementing. We don't necessarily have to implement all the
rest either.
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.
I too think #4 is the right default. If we implement any others, the
user could select them with variables set in .emacs, or with
emacsclient options.
Re: Change in emacsclient behavior, Edward O'Connor, 2007/09/03