Re: Change in emacsclient behavior

[Richard Stallman]

    > 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.