unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Davis Herring" <herring@lanl.gov>
To: "Juri Linkov" <juri@jurta.org>
Cc: emacs-devel@gnu.org
Subject: Re: Change in emacsclient behavior
Date: Tue, 4 Sep 2007 16:08:24 -0700 (PDT)	[thread overview]
Message-ID: <59272.128.165.123.18.1188947304.squirrel@webmail.lanl.gov> (raw)
In-Reply-To: <87veatxcrz.fsf@jurta.org>

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

  parent reply	other threads:[~2007-09-04 23:08 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-30 20:50 Change in emacsclient behavior Richard Stallman
2007-08-30 21:04 ` Drew Adams
2007-08-31 18:21   ` Richard Stallman
2007-08-31 18:26     ` Drew Adams
2007-08-30 21:23 ` Eli Zaretskii
2007-08-30 21:41   ` Henrik Enberg
2007-08-31 18:21   ` Richard Stallman
2007-09-01  7:41     ` Eli Zaretskii
2007-09-01  8:26       ` David Kastrup
2007-08-31  6:39 ` Stefan Monnier
2007-08-31  8:06   ` Tassilo Horn
2007-08-31 14:31     ` Stefan Monnier
2007-09-02 18:52     ` Juri Linkov
2007-09-02 19:20       ` David Kastrup
2007-09-02 20:14         ` Juri Linkov
2007-09-02 20:34           ` David Kastrup
2007-09-02 20:44             ` Tom Tromey
2007-09-03 18:26           ` Richard Stallman
2007-09-02 23:20         ` Manoj Srivastava
2007-09-02 19:34       ` Tassilo Horn
2007-09-02 20:14         ` Juri Linkov
2007-09-03 19:15           ` Tassilo Horn
2007-09-03 15:31       ` Jeremy Maitin-Shepard
2007-09-03 18:26       ` Richard Stallman
2007-09-03 20:37       ` Stefan Monnier
2007-09-03 23:46         ` Juri Linkov
2007-09-04 23:08       ` Davis Herring [this message]
2007-09-05 20:02         ` Richard Stallman
2007-09-05 20:34           ` David Kastrup
2007-09-07  6:30             ` Richard Stallman
2007-09-07  7:06               ` David Kastrup
2007-09-08  7:01                 ` Richard Stallman
2007-08-31  8:09   ` David Kastrup
2007-08-31 14:29     ` Stefan Monnier
2007-09-03  5:47 ` Edward O'Connor
2007-09-04  0:56   ` Richard Stallman
2007-09-04  5:56     ` David Kastrup
2007-09-04 22:57       ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59272.128.165.123.18.1188947304.squirrel@webmail.lanl.gov \
    --to=herring@lanl.gov \
    --cc=emacs-devel@gnu.org \
    --cc=juri@jurta.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).