Change in emacsclient behavior

Change in emacsclient behavior

[Richard Stallman]

I think this change is a mistake:

    +** Emacsclient has been extended to support opening a new terminal
    +frame.  Its behavior has been changed to open a new Emacs frame by
    +default.  Use the -c option to get the old behavior of opening files in
    +the currently selected Emacs frame.

For people that normally don't make new frames, this will be a hassle.
So I think it should depend on the value of `pop-up-frames'.

Are there any arguments against testing `pop-up-frames'?

RE: Change in emacsclient behavior

[Drew Adams]

> I think this change is a mistake:
>
>     +** Emacsclient has been extended to support opening a new terminal
>     +frame.  Its behavior has been changed to open a new Emacs frame by
>     +default.  Use the -c option to get the old behavior of
> opening files in
>     +the currently selected Emacs frame.
>
> For people that normally don't make new frames, this will be a hassle.
> So I think it should depend on the value of `pop-up-frames'.
>
> Are there any arguments against testing `pop-up-frames'?

I have no argument against that test. However, testing non-nil
`pop-up-frames' is not always a sufficient indication that a user wants a
separate frame.

`special-display-regexps' and `special-display-buffer-names' can also
indicate a user wish for a separate frame. If a file name matches one of
these, then perhaps emacslient should use a separate frame. (I don't know
whether that already happens.)

Re: Change in emacsclient behavior

[Richard Stallman]

    `special-display-regexps' and `special-display-buffer-names' can also
    indicate a user wish for a separate frame. If a file name matches one of
    these, then perhaps emacslient should use a separate frame. (I don't know
    whether that already happens.)

I think those will take effect anyway, right?
If not, I agree it could make sense to check them.

RE: Change in emacsclient behavior

[Drew Adams]

>     `special-display-regexps' and `special-display-buffer-names' can also
>     indicate a user wish for a separate frame. If a file name 
>     matches one of these, then perhaps emacslient should use a separate
>     frame. (I don't know whether that already happens.)
> 
> I think those will take effect anyway, right?
> If not, I agree it could make sense to check them.

I guess you mean that emacsclient already opens them in separate frames. 

I don't know whether it's true. I haven't yet tried the new emacsclient.

Re: Change in emacsclient behavior

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 30 Aug 2007 16:50:22 -0400
> 
> I think this change is a mistake:
> 
>     +** Emacsclient has been extended to support opening a new terminal
>     +frame.  Its behavior has been changed to open a new Emacs frame by
>     +default.  Use the -c option to get the old behavior of opening files in
>     +the currently selected Emacs frame.
> 
> For people that normally don't make new frames, this will be a hassle.

Yes, I agree.  Frames popping up without my say-so are a nuisance.

Re: Change in emacsclient behavior

[Henrik Enberg]

Eli Zaretskii <eliz@gnu.org> writes:
> > From: Richard Stallman <rms@gnu.org>
> > Date: Thu, 30 Aug 2007 16:50:22 -0400
> > 
> > I think this change is a mistake:
> > 
> >     +** Emacsclient has been extended to support opening a new terminal
> >     +frame.  Its behavior has been changed to open a new Emacs frame by
> >     +default.  Use the -c option to get the old behavior of opening files in
> >     +the currently selected Emacs frame.
> > 
> > For people that normally don't make new frames, this will be a hassle.
> 
> Yes, I agree.  Frames popping up without my say-so are a nuisance.

Thirded.  There should however be an arg to pop up a new frame even
when pop-up-frames is nil.

Re: Change in emacsclient behavior

[Richard Stallman]

    > For people that normally don't make new frames, this will be a hassle.

    Yes, I agree.  Frames popping up without my say-so are a nuisance.

Would you like to fix this?

Re: Change in emacsclient behavior

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: emacs-devel@gnu.org
> Date: Fri, 31 Aug 2007 14:21:35 -0400
> 
>     > For people that normally don't make new frames, this will be a hassle.
> 
>     Yes, I agree.  Frames popping up without my say-so are a nuisance.
> 
> Would you like to fix this?

I don't think this is a good idea, since my free time will be severely
limited in the near future, and on top of that, I'm not familiar at
all with the multi-tty code and the changes it introduced into Emacs.

Sorry.

Re: Change in emacsclient behavior

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> CC: emacs-devel@gnu.org
>> Date: Fri, 31 Aug 2007 14:21:35 -0400
>> 
>>     > For people that normally don't make new frames, this will be a hassle.
>> 
>>     Yes, I agree.  Frames popping up without my say-so are a nuisance.
>> 
>> Would you like to fix this?
>
> I don't think this is a good idea, since my free time will be
> severely limited in the near future, and on top of that, I'm not
> familiar at all with the multi-tty code and the changes it
> introduced into Emacs.

It is not like we have an abundance of those who are familiar with it
and have time working on it.  Is there even one?  At least, the set
might be so small that it does not include people beyond the creators,
so they might not be overly inclined to back out changes they
considered a good idea.

As far as I can tell, multi-tty is one package including several
things, some of which may more reflect the author's personal
preferences rather than actual technical requirements for the
multi-tty functionality.

Boiling down the multi-tty work to a level where it basically includes
those things necessary and desirable will be work.  It might have been
easier to manage while there was still a separate branch, but there
was ample opportunity to do so before the merge, and it did not really
make people work on that (myself very much included).  Like before,
things don't fix and document and simplify themselves.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Change in emacsclient behavior

[Stefan Monnier]

> I think this change is a mistake:
>     +** Emacsclient has been extended to support opening a new terminal
>     +frame.  Its behavior has been changed to open a new Emacs frame by
>     +default.  Use the -c option to get the old behavior of opening files in
>     +the currently selected Emacs frame.

> For people that normally don't make new frames, this will be a hassle.

Agreed.  It may also be a hassle for people who use multiple frames because
IIUC it will create only one frame per emacsclient rather than one per file,
like I use.

> So I think it should depend on the value of `pop-up-frames'.

I disagree.  It should just revert to the old behavior (i.e. revert the
"-c" arg to emacsclient).

> Are there any arguments against testing `pop-up-frames'?

If I understand the code correctly, the choice is made in emacsclient, so it
does not have access to `pop-up-frames' anyway.


        Stefan

Re: Change in emacsclient behavior

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I think this change is a mistake:
>>     +** Emacsclient has been extended to support opening a new terminal
>>     +frame.  Its behavior has been changed to open a new Emacs frame by
>>     +default.  Use the -c option to get the old behavior of opening files in
>>     +the currently selected Emacs frame.
>
>> For people that normally don't make new frames, this will be a
>> hassle.
>
> Agreed.  It may also be a hassle for people who use multiple frames
> because IIUC it will create only one frame per emacsclient rather than
> one per file, like I use.
>
>> So I think it should depend on the value of `pop-up-frames'.
>
> I disagree.  It should just revert to the old behavior (i.e. revert
> the "-c" arg to emacsclient).

Normally I don't use several frames, but for emacsclients I like the new
behavior.  Making it depend on pop-up-frames wouldn't help me, so I'm
for the reversed behavior of the -c option, too.

But then -c --current-frame would't make sense.  How about -m
--make-frame?

BTW: The man page needs to be updated, too.

Bye,
Tassilo
-- 
Chuck Norris has  never won an Academy Award  for acting... because he's
not acting.

Re: Change in emacsclient behavior

[Stefan Monnier]

> But then -c --current-frame would't make sense.  How about -m
> --make-frame?

IIUC the "-c" argument doesn't do "current-frame" so its name is misleading
(with my .emacs config at least, with "-c" a new frame is created for every
file).

It seems that "-c" mostly does "old style" vs "new style", where the new
style is to try and pretend that emacsclient started a new process
(i.e. make it behave as much as a possible like a new Emacs session, just
started more quickly and sharing its buffers with the old session).

But I haven't read enough of the code yet to be quite sure this is the case.


        Stefan

Re: Change in emacsclient behavior

[Juri Linkov]

> Normally I don't use several frames, but for emacsclients I like the new
> behavior.  Making it depend on pop-up-frames wouldn't help me, so I'm
> for the reversed behavior of the -c option, too.

How about the following default behavior of emacsclient:

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

2. When invoked with -e or --eval, display the current frame and eval the
expression on this frame.

3. When invoked with one FILE argument, create a new frame with the file
buffer.

4. When invoked with multiple FILE arguments, create either one frame with
windows containing all specified files' buffers, or if `pop-up-frames' is
non-nil, create as many frames as there are file arguments (starting a new
Emacs session already does this).

The reason that is usually it's undesirable to change the window configuration
of the current frame when visiting new files.  However, evaluation of the
expression can change it as well, e.g. emacsclient -e '(info)'.  So the
argument -c is still needed to force either creating a new frame or using
the current one.  Of course, when parsing is done on the Emacs side, this
gives the user more power to decide what exactly to do.

> But then -c --current-frame would't make sense.

One possible mnemonic for -c is --create-frame.

BTW, does anyone know how to start a detached Emacs server so that after
logout and login I could connect to it with emacsclient?

I tried

  nohup emacs -nw -f server-start

but it writes to nohup.out

  emacs: standard input is not a tty

and exits.  Then I tried with the -batch argument, but this
doesn't work neither.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Change in emacsclient behavior

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> Normally I don't use several frames, but for emacsclients I like
>> the new behavior.  Making it depend on pop-up-frames wouldn't help
>> me, so I'm for the reversed behavior of the -c option, too.
>
> How about the following default behavior of emacsclient:

I don't think that it makes sense to fantasize a whole bunch of
behaviors for emacsclient: emacsclient should be modeled to mimic
Emacs itself as closely as possible with regard to command line
options and stuff: that way, one does not need half a million of info
pages to explain how clever it is.

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

Initial frame seems reasonable.

> 2. When invoked with -e or --eval, display the current frame and eval the
> expression on this frame.
>
> 3. When invoked with one FILE argument, create a new frame with the file
> buffer.
>
> 4. When invoked with multiple FILE arguments, create either one frame with
> windows containing all specified files' buffers, or if `pop-up-frames' is
> non-nil, create as many frames as there are file arguments (starting a new
> Emacs session already does this).

Too much cleverness.  Just do the same thing that is done on normal
Emacs startup.

> The reason that is usually it's undesirable to change the window
> configuration of the current frame when visiting new files.

That is no different from C-x C-f.

I can imagine one thing that could conceivably made to differentiate
between "C-x C-f"-like and "new Emacs session"-like behavior: if tty
and/or TERM indicate that emacsclient has been started from _within_
Emacs (for example, as an editor from a CVS command inside of an Emacs
shell or VC), then it does make more sense to treat this "C-x
C-f"-like than when emacsclient gets started from an independent
tty/terminal.


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Change in emacsclient behavior

[Juri Linkov]

> I don't think that it makes sense to fantasize a whole bunch of
> behaviors for emacsclient: emacsclient should be modeled to mimic
> Emacs itself as closely as possible with regard to command line
> options and stuff: that way, one does not need half a million of info
> pages to explain how clever it is.

I agree that emacsclient should mimic emacs as much as possible.
Maybe even there should be a common wrapper (with a different name)
for emacs and emacsclient: running it will start emacs if it is
not started yet or connect to an existing Emacs server.

At least, command line options shouldn't be so different as now,
e.g. instead of -t, --tty better to use --no-window-system, -nw...

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Change in emacsclient behavior

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

>> I don't think that it makes sense to fantasize a whole bunch of
>> behaviors for emacsclient: emacsclient should be modeled to mimic
>> Emacs itself as closely as possible with regard to command line
>> options and stuff: that way, one does not need half a million of info
>> pages to explain how clever it is.
>
> I agree that emacsclient should mimic emacs as much as possible.
> Maybe even there should be a common wrapper (with a different name)
> for emacs and emacsclient: running it will start emacs if it is
> not started yet or connect to an existing Emacs server.

emacsclient -a emacs

> At least, command line options shouldn't be so different as now,
> e.g. instead of -t, --tty better to use --no-window-system, -nw...

I want to be able to say something like

emacsclient -a emacs -f emerge-files-command file-a file-b file-c

and have it work as expected.  It is not too hard to do if one leaves
the command line parsing mainly to emacs-server and have it set up
(and then consume) command-line-args-left.  The ugly part is probably
rerouting kill-emacs (called in emerge-command-exit) within the Emacs
server.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Change in emacsclient behavior

[Tom Tromey]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

David> I want to be able to say something like
David> emacsclient -a emacs -f emerge-files-command file-a file-b file-c
David> and have it work as expected.

I've been wanting this for 'gdb --args' for a while now.  Currently
I'm using a hack in shell-mode that looks for gdb and instead invokes
M-x gdb.  This is nice but not perfect -- first of all, due to
longstanding habit I'm not much of a shell-mode user; and second, this
doesn't work in all the places where 'gdb --args' may work
(specifically I want to be able to be able to run gcc sub-processes
using the debugger, i.e., script it).

Tom

Re: Change in emacsclient behavior

[Richard Stallman]

    I agree that emacsclient should mimic emacs as much as possible.
    Maybe even there should be a common wrapper (with a different name)
    for emacs and emacsclient: running it will start emacs if it is
    not started yet or connect to an existing Emacs server.

We already have such a wrapper, as a script in etc.

    At least, command line options shouldn't be so different as now,
    e.g. instead of -t, --tty better to use --no-window-system, -nw...

That is a good idea.  Would someone please implement it?

      It is not too hard to do if one leaves
    the command line parsing mainly to emacs-server and have it set up
    (and then consume) command-line-args-left.

That is also a good implementation idea, if it works out.

Re: Change in emacsclient behavior

[Manoj Srivastava]

On Sun, 02 Sep 2007 21:20:57 +0200, David Kastrup <dak@gnu.org> said: 

> Juri Linkov <juri@jurta.org> writes:
>>> Normally I don't use several frames, but for emacsclients I like the
>>> new behavior.  Making it depend on pop-up-frames wouldn't help me,
>>> so I'm for the reversed behavior of the -c option, too.
>> 
>> How about the following default behavior of emacsclient:

> I don't think that it makes sense to fantasize a whole bunch of
> behaviors for emacsclient: emacsclient should be modeled to mimic
> Emacs itself as closely as possible with regard to command line
> options and stuff: that way, one does not need half a million of info
> pages to explain how clever it is.

        As an end user, would it still be possible to specify easily
 whether one  wants to 
  a) reuse an existing frame (which is something I do not often want --
     existing frame is usually detached behind screen or sitting on
     another window manager pane) 
  b) Pop up one frame per emacsclient invocation and work through files
     one at a time in that frame (using C-x #), with the frame being
     removed when all files are done) -- this is my preferred mode of
     operation
  c) have one frame pop up per file (That could be nice, for a few files).

        I can get b) from current emacsclient; I used to get c) from
 gnuclient, and the old emacsclient used to give me a).

        manoj
-- 
What is irritating about love is that it is a crime that requires an
accomplice. Charles Baudelaire
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Change in emacsclient behavior

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

Hi Juri,

>> Normally I don't use several frames, but for emacsclients I like the
>> new behavior.  Making it depend on pop-up-frames wouldn't help me, so
>> I'm for the reversed behavior of the -c option, too.
>
> How about the following default behavior of emacsclient:
>
> 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).
>
> 2. When invoked with -e or --eval, display the current frame and eval
> the expression on this frame.

I don't quite understand what is the "current" frame.  What if you have
several frames, none of which has the focus.  Which one is current then?
The last visited one?

> 3. When invoked with one FILE argument, create a new frame with the
> file buffer.
>
> 4. When invoked with multiple FILE arguments, create either one frame
> with windows containing all specified files' buffers, or if
> `pop-up-frames' is non-nil, create as many frames as there are file
> arguments (starting a new Emacs session already does this).

Sounds good to me.

>> But then -c --current-frame would't make sense.
>
> One possible mnemonic for -c is --create-frame.

Agreed.

> BTW, does anyone know how to start a detached Emacs server so that
> after logout and login I could connect to it with emacsclient?

I use screen for that:

    screen -d -m -S EmacsServer emacs -nw

Bye,
Tassilo
-- 
The air around Chuck Norris is always a balmy 78 degrees. 

Re: Change in emacsclient behavior

[Juri Linkov]

> I don't quite understand what is the "current" frame.  What if you have
> several frames, none of which has the focus.  Which one is current then?
> The last visited one?

It seems the "current" frame is the last created one.

>> BTW, does anyone know how to start a detached Emacs server so that
>> after logout and login I could connect to it with emacsclient?
>
> I use screen for that:
>
>     screen -d -m -S EmacsServer emacs -nw

Thanks.  I thought that it would be possible to do this without screens
somehow.  I see there are two useful scripts in admin/notes/multi-tty.
Perhaps they should be placed in the bin/ directory with more suitable
names like `emacs-connect' and `emacs-preload'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Change in emacsclient behavior

[Tassilo Horn]

Juri Linkov <juri@jurta.org> writes:

Hi Juri,

>>> BTW, does anyone know how to start a detached Emacs server so that
>>> after logout and login I could connect to it with emacsclient?
>>
>> I use screen for that:
>>
>>     screen -d -m -S EmacsServer emacs -nw
>
> Thanks.  I thought that it would be possible to do this without
> screens somehow.  I see there are two useful scripts in
> admin/notes/multi-tty.  Perhaps they should be placed in the bin/
> directory with more suitable names like `emacs-connect' and
> `emacs-preload'?

Hey, nice!  But they use screen, too.  I don't know if it's ok to place
them there when they won't work if screen's not installed.  But they
should definitely get a more prominent place where users can find them.
Maybe in etc/ and mention them in the docs?

Bye,
Tassilo

Re: Change in emacsclient behavior

[Jeremy Maitin-Shepard]

Juri Linkov <juri@jurta.org> writes:

>> Normally I don't use several frames, but for emacsclients I like the new
>> behavior.  Making it depend on pop-up-frames wouldn't help me, so I'm
>> for the reversed behavior of the -c option, too.

> How about the following default behavior of emacsclient:

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

What does it mean to "display" a frame?

> 2. When invoked with -e or --eval, display the current frame and eval the
> expression on this frame.

Why is it even useful to "display" a frame before evaluating the
expression?  I think it is important to have a way to evaluate an
expression without any other side effects.  In particular, it is
important to be able to evaluate an expression without quitting out of a
minibuffer prompt.  (I don't know if that problem still exists.)

[snip]

I think it is most important that emacsclient provides a sufficient
interface for achieving all possible desirable behavior.  Users can then
create their own shell scripts, aliases, etc. that can be used with the
desired syntax.  The actual syntax that the base emacsclient program
provides is of very marginal importance.

> BTW, does anyone know how to start a detached Emacs server so that after
> logout and login I could connect to it with emacsclient?

> I tried

>   nohup emacs -nw -f server-start

> but it writes to nohup.out

>   emacs: standard input is not a tty

> and exits.  Then I tried with the -batch argument, but this
> doesn't work neither.

You can use screen.

-- 
Jeremy Maitin-Shepard

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

Ok.

    2. When invoked with -e or --eval, display the current frame and eval the
    expression on this frame.

Ok.

    3. When invoked with one FILE argument, create a new frame with the file
    buffer.

No.  emacsclient should, by default, display files the same way C-x C-f does.
server.el should simply call find-file.

We already have lots of ways to customize C-x C-f, and we can add more
if users want them.  If server.el simply calls find-file, all these
customization mechanisms will be available for it.

    4. When invoked with multiple FILE arguments, create either one frame with
    windows containing all specified files' buffers,

No, for the same reason.

						     or if `pop-up-frames' is
    non-nil, create as many frames as there are file arguments (starting a new
    Emacs session already does this).

That seems plausible for the case where `pop-up-frames' is non-nil.

Re: Change in emacsclient behavior

[Stefan Monnier]

> How about the following default behavior of emacsclient:

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

> 2. When invoked with -e or --eval, display the current frame and eval the
> expression on this frame.

> 3. When invoked with one FILE argument, create a new frame with the file
> buffer.

> 4. When invoked with multiple FILE arguments, create either one frame with
> windows containing all specified files' buffers, or if `pop-up-frames' is
> non-nil, create as many frames as there are file arguments (starting a new
> Emacs session already does this).

I think most of those decisions are better placed in the user's .emacs than
on the emacsclient commandline.

Looking at the description above I always get nightmares of make-frame and
switch-to-buffer (the first having the problem of generating non-dedicated
frames, and the other having the problem of failing in several
circumstances and doing the wrong thing in others).  If you want to obey
pop-up-frames, then please use display-buffer (or pop-to-buffer).


        Stefan

Re: Change in emacsclient behavior

[Juri Linkov]

> I think most of those decisions are better placed in the user's .emacs
> than on the emacsclient commandline.

Since one does not rule out another, for trivial decisions (like either
to create a new frame or not) we can use the command line arguments, and
use .emacs for more complex customizations (possibly overriding the command
line arguments).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Change in emacsclient behavior

[Davis Herring]

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

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.

Re: Change in emacsclient behavior

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

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

It would make it possible to configure an Emacsclient invocation as a
$PAGER command.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Change in emacsclient behavior

[Richard Stallman]

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

    It would make it possible to configure an Emacsclient invocation as a
    $PAGER command.

Sorry, I do not follow.

Re: Change in emacsclient behavior

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

Richard Stallman <rms@gnu.org> writes:

>     >     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.
>
>     It would make it possible to configure an Emacsclient invocation
>     as a $PAGER command.
>
> Sorry, I do not follow.

Executables like "man" use a pager configurable in $PAGER for their
output.  Calling man in an Emacs shell session creates a lot of
garbage due to terminal problems.  It would be much nicer if one could
configure something into $PAGER which just sucked up its stdin and
made it available in a separate Emacs buffer in view mode.  In fact, I
_have_ something like that configured as a pager, namely the following
executable:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacs-pager --]
[-- Type: text/x-sh, Size: 264 bytes --]

#!/bin/sh
TMP=`mktemp -t emacs-pager.XXXXXX`
trap "rm $TMP* 2>/dev/null" 0
echo '-*- mode: view; auto-revert-interval: 1; mode: auto-revert-tail; view-exit-action: kill-buffer -*-' >"$TMP"
exec 5<&0 <&-
cat "$@" <&5 >>"$TMP" &
eval "${VISUAL:-${EDITOR}}" '"$TMP"'

[-- Attachment #3: Type: text/plain, Size: 403 bytes --]


Now this has several drawbacks: it takes a longer startup time, it
needs a temporary file, and it does not stop the data generating
process when the material will not get read to its end, anyway.

For example (a useless example, agreed),

yes|$PAGER

works well with $PAGER being less and/or more, but redirecting to a
temporary file is not so great.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Change in emacsclient behavior

[Richard Stallman]

      It would be much nicer if one could
    configure something into $PAGER which just sucked up its stdin and
    made it available in a separate Emacs buffer in view mode.

I see the idea now.
Thanks.

Re: Change in emacsclient behavior

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I think this change is a mistake:
>>     +** Emacsclient has been extended to support opening a new terminal
>>     +frame.  Its behavior has been changed to open a new Emacs frame by
>>     +default.  Use the -c option to get the old behavior of opening files in
>>     +the currently selected Emacs frame.
>
>> For people that normally don't make new frames, this will be a hassle.
>
> Agreed.  It may also be a hassle for people who use multiple frames because
> IIUC it will create only one frame per emacsclient rather than one per file,
> like I use.
>
>> So I think it should depend on the value of `pop-up-frames'.
>
> I disagree.  It should just revert to the old behavior (i.e. revert the
> "-c" arg to emacsclient).
>
>> Are there any arguments against testing `pop-up-frames'?
>
> If I understand the code correctly, the choice is made in emacsclient, so it
> does not have access to `pop-up-frames' anyway.

Here is my take on that from looking over the old emacsclient code (so
of course the take is out of date):

It really does not make any sense to let emacsclient do the option
parsing.  It is much more flexible to let the server deal with that
since we then have the full power of Elisp available and all
information and variables we might want.  So emacsclient should just
parse those initial options it needs to contact Emacs, and then hand
over the rest, and then set itself into a loop where it just does
Emacs' bidding.

This bidding could include
- request particular environment variables (typically TERM and/or
   DISPLAY)

- request a line from stdin (or specified file descriptor)

- send data to stdout (or specified file descriptor)

- request the tty name

- for later: if the connection is non-local, tty control might be
  interesting: Emacs would then be talking to the terminal through
  Emacsclient as a proxy.

- exit with given exit status

Anything else is best dealt with on the Emacsserver side, I think.

-- 
David Kastrup

Re: Change in emacsclient behavior

[Stefan Monnier]

> It really does not make any sense to let emacsclient do the option
> parsing.  It is much more flexible to let the server deal with that
> since we then have the full power of Elisp available and all
> information and variables we might want.  So emacsclient should just
> parse those initial options it needs to contact Emacs, and then hand
> over the rest, and then set itself into a loop where it just does
> Emacs' bidding.

I don't know enough of the details yet either, but on principle I agree that
emacsclient should be as stripped down as possible, so that most of the
decisions (and code) is on the server.el side.


        Stefan

Re: Change in emacsclient behavior

[Edward O'Connor]

Richard Stallman <rms@gnu.org> writes:

> I think this change is a mistake:
>     +** Emacsclient has been extended to support opening a new terminal
>     +frame.  Its behavior has been changed to open a new Emacs frame by
>     +default.  Use the -c option to get the old behavior of opening files in
>     +the currently selected Emacs frame.

> For people that normally don't make new frames, this will be a hassle.
> So I think it should depend on the value of `pop-up-frames'.

> Are there any arguments against testing `pop-up-frames'?

To me, the main usefulness of multi-tty functionality is for when I'm
remotely logging in to a machine on which I already have a long-running
Emacs. For instance, on workstation A I have an Emacs running with X11
frames. I SSH into A from some other machine B, and would like to open a
TTY frame within that SSH session.

I think this, or situations similar to it, is the scenario envisioned by
the change in emacsclient -- note the NEWS entry specifically calls out
the support for "opening a new *terminal* frame."

So, yes, I don't normally make new frames, but `pop-up-frames' strikes
me as precisely the wrong variable to test in this scenario. Also,
popping up the existing X11 frame does no good in this case.

Re: Change in emacsclient behavior

[Richard Stallman]

    To me, the main usefulness of multi-tty functionality is for when I'm
    remotely logging in to a machine on which I already have a long-running
    Emacs.

With all due respect, that is not a major factor in choosing the
interface of emacsclient.  Whatever interface we choose for it will
apply to ALL use of emacsclient.  Not only to the occasional cases
where you actually take advantage of the multi-tty functionality.
We have to choose it for the usual case.

Re: Change in emacsclient behavior

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     To me, the main usefulness of multi-tty functionality is for when I'm
>     remotely logging in to a machine on which I already have a long-running
>     Emacs.
>
> With all due respect, that is not a major factor in choosing the
> interface of emacsclient.  Whatever interface we choose for it will
> apply to ALL use of emacsclient.  Not only to the occasional cases
> where you actually take advantage of the multi-tty functionality.
> We have to choose it for the usual case.

It is difficult _not_ to "take advantage" of the multi-tty
functionality right now.  Using emacsclient will start a new "terminal
session" at least with the current setup, with a completely separate
set of environment variables and other stuff.

And this will be the default setting for a number of people whose
working style this suits.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Change in emacsclient behavior

[Richard Stallman]

    It is difficult _not_ to "take advantage" of the multi-tty
    functionality right now.

He was talking about the cases when he finds multi-tty functionality
useful.

			      Using emacsclient will start a new "terminal
    session" at least with the current setup, with a completely separate
    set of environment variables and other stuff.

I think that is wrong design; I've decided that the default
for emacsclient should be to use an existing frame.