emacsclient bug

emacsclient bug

[Len Trigg]

I use emacs pretty much exclusively in multi-tty mode, seldom creating
actual X frames.  I recently switched from the pre-emacs-22 multi-tty
branch to the new emacs-23 snapshot (from a few days ago) and have
noticed some changes.

1) Start a new emacs in a tty

2) (server-start)

3) In another shell, do:
   $ emacsclient <somefilename>

4) BUG: emacs opens a new frame.  It should instead load into my
existing emacs tty.  The old multi-tty emacsclient did this correctly
(although it needed a flag, --current-frame, since superseded by the
reverse --create-frame, to achieve this).



Another problem (I'm not sure if it previously existed), is that if
you specify the --no-wait option, but the file to be loaded causes a
minibuffer prompt (e.g.: if the file is a symlink), the emacsclient
does in fact wait (until the minibuffer prompt is answered).



Cheers,
Len.

Re: emacsclient bug

[Stefan Monnier]

> I use emacs pretty much exclusively in multi-tty mode, seldom creating
> actual X frames.  I recently switched from the pre-emacs-22 multi-tty
> branch to the new emacs-23 snapshot (from a few days ago) and have
> noticed some changes.

> 1) Start a new emacs in a tty

> 2) (server-start)

> 3) In another shell, do:
>    $ emacsclient <somefilename>

> 4) BUG: emacs opens a new frame.  It should instead load into my
> existing emacs tty.  The old multi-tty emacsclient did this correctly

This is not a bug: the behavior was chosen to better match the previous
non-multi-tty behavior.  You need to add the "-t" argument to tell
emacsclient to open a new frame in the local tty.


        Stefan

Re: emacsclient bug

[Len Trigg]

On 18/01/2008, at 4:42 AM, Stefan Monnier <monnier@iro.umontreal.ca>  
wrote:

>> I use emacs pretty much exclusively in multi-tty mode, seldom  
>> creating
>> actual X frames.  I recently switched from the pre-emacs-22 multi-tty
>> branch to the new emacs-23 snapshot (from a few days ago) and have
>> noticed some changes.
>
>> 1) Start a new emacs in a tty
>
>> 2) (server-start)
>
>> 3) In another shell, do:
>>   $ emacsclient <somefilename>
>
>> 4) BUG: emacs opens a new frame.  It should instead load into my
>> existing emacs tty.  The old multi-tty emacsclient did this correctly
>
> This is not a bug: the behavior was chosen to better match the  
> previous
> non-multi-tty behavior.  You need to add the "-t" argument to tell
> emacsclient to open a new frame in the local TTY.

But that is not what I want. I want it to open in my existing TTY. How  
can I achieve that? It doesn't seem possible any more.

Cheers,
Len

Re: emacsclient bug

[Len Trigg]

Stefan Monnier wrote:
> 
> > I use emacs pretty much exclusively in multi-tty mode, seldom creating
> > actual X frames.  I recently switched from the pre-emacs-22 multi-tty
> > branch to the new emacs-23 snapshot (from a few days ago) and have
> > noticed some changes.
> 
> > 1) Start a new emacs in a tty
> 
> > 2) (server-start)
> 
> > 3) In another shell, do:
> >    $ emacsclient <somefilename>
> 
> > 4) BUG: emacs opens a new frame.  It should instead load into my
> > existing emacs tty.  The old multi-tty emacsclient did this correctly
> 
> This is not a bug: the behavior was chosen to better match the previous
> non-multi-tty behavior.  You need to add the "-t" argument to tell
> emacsclient to open a new frame in the local tty.

I should add that I think the bug is only after freshly invoking
server-start -- if you create a tty emacsclient (with emacsclient -t)
in another tty, then step 3 will result in somefilename being opened
in an existing tty frame (as desired).

Cheers,
Len.

Re: emacsclient bug

[Stefan Monnier]

>> > I use emacs pretty much exclusively in multi-tty mode, seldom creating
>> > actual X frames.  I recently switched from the pre-emacs-22 multi-tty
>> > branch to the new emacs-23 snapshot (from a few days ago) and have
>> > noticed some changes.
>> 
>> > 1) Start a new emacs in a tty
>> 
>> > 2) (server-start)
>> 
>> > 3) In another shell, do:
>> >    $ emacsclient <somefilename>
>> 
>> > 4) BUG: emacs opens a new frame.  It should instead load into my
>> > existing emacs tty.  The old multi-tty emacsclient did this correctly
>> 
>> This is not a bug: the behavior was chosen to better match the previous
>> non-multi-tty behavior.  You need to add the "-t" argument to tell
>> emacsclient to open a new frame in the local tty.

> I should add that I think the bug is only after freshly invoking
> server-start -- if you create a tty emacsclient (with emacsclient -t)
> in another tty, then step 3 will result in somefilename being opened
> in an existing tty frame (as desired).

Hmm... looks like I misunderstood the original bug.
Are you saying that if you start

  tty1> emacs -f emacs-server
  tty2> emacsclient foo.bar

that the emacsclient causes a new frame to be opened in tty2 or in tty1
(it should be in tty1)?


        Stefan

Re: emacsclient bug

[Len Trigg]

Stefan Monnier wrote:
> Hmm... looks like I misunderstood the original bug.
> Are you saying that if you start
> 
>   tty1> emacs -f emacs-server
>   tty2> emacsclient foo.bar
> 
> that the emacsclient causes a new frame to be opened in tty2 or in tty1
> (it should be in tty1)?

Yes, it should be in tty1, but it opens a new emacs X window!

Cheers,
Len.

Re: emacsclient bug

[Stefan Monnier]

>> Hmm... looks like I misunderstood the original bug.
>> Are you saying that if you start
>> 
tty1> emacs -f emacs-server
tty2> emacsclient foo.bar
>> 
>> that the emacsclient causes a new frame to be opened in tty2 or in tty1
>> (it should be in tty1)?

> Yes, it should be in tty1, but it opens a new emacs X window!

Oh, yes, I see.  It's another effect of the behavior where having
a DISPLAY envvar has the same effect as passing "-display $DISPLAY".
I think we should revert this change as well.


        Stefan

Re: emacsclient bug

[Len Trigg]

Stefan Monnier wrote:
> Oh, yes, I see.  It's another effect of the behavior where having
> a DISPLAY envvar has the same effect as passing "-display $DISPLAY".
> I think we should revert this change as well.

It sounds like the problem is larger than just treating DISPLAY as an
implicit -display parameter.  If I pass -display $DISPLAY, would emacs
also incorrectly open a new frame, rather than using the existing tty
(assuming I supply neither -c or -t)?


Cheers,
Len.

Re: emacsclient bug

[Len Trigg]

Stefan Monnier wrote:
> Oh, yes, I see.  It's another effect of the behavior where having
> a DISPLAY envvar has the same effect as passing "-display $DISPLAY".
> I think we should revert this change as well.

It sounds like the problem is larger than just treating DISPLAY as an
implicit -display parameter.  If I pass -display $DISPLAY, would emacs
also incorrectly open a new frame, rather than using the existing tty
(assuming I supply neither -c or -t)?


Cheers,
Len.

Re: emacsclient bug

[Stefan Monnier]

>> Oh, yes, I see.  It's another effect of the behavior where having
>> a DISPLAY envvar has the same effect as passing "-display $DISPLAY".
>> I think we should revert this change as well.

> It sounds like the problem is larger than just treating DISPLAY as an
> implicit -display parameter.  If I pass -display $DISPLAY, would emacs
> also incorrectly open a new frame, rather than using the existing tty
> (assuming I supply neither -c or -t)?

Of course it would open a new X11 frame: That's what `-display' is for.


        Stefan

Re: emacsclient bug

[Len Trigg]

Stefan Monnier wrote:
> > It sounds like the problem is larger than just treating DISPLAY as an
> > implicit -display parameter.  If I pass -display $DISPLAY, would emacs
> > also incorrectly open a new frame, rather than using the existing tty
> > (assuming I supply neither -c or -t)?
> 
> Of course it would open a new X11 frame: That's what `-display' is for.

I had always thought of --display and $DISPLAY as fulfilling the same
function, setting the name of your X server, rather than an
instruction to perform an action (open a window when you otherwise
wouldn't).  The other behaviour of emacs is consistent with this
interpretation:

emacs -nw --display $DISPLAY        (opens in tty)
emacsclient -t --display $DISPLAY   (opens in tty)


Cheers,
Len.

Re: emacsclient bug

[Andreas Schwab]

Len Trigg <lenbok@gmail.com> writes:

> I had always thought of --display and $DISPLAY as fulfilling the same
> function, setting the name of your X server, rather than an
> instruction to perform an action (open a window when you otherwise
> wouldn't).

It also establishes a default.  When you don't pass -nw then emacs uses
the presence of $DISPLAY/-display to decide whether to use a tty or X11
frame.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacsclient bug

[Stefan Monnier]

>> > It sounds like the problem is larger than just treating DISPLAY as an
>> > implicit -display parameter.  If I pass -display $DISPLAY, would emacs
>> > also incorrectly open a new frame, rather than using the existing tty
>> > (assuming I supply neither -c or -t)?
>> 
>> Of course it would open a new X11 frame: That's what `-display' is for.

> I had always thought of --display and $DISPLAY as fulfilling the same
> function, setting the name of your X server, rather than an
> instruction to perform an action (open a window when you otherwise
> wouldn't).  The other behaviour of emacs is consistent with this
> interpretation:

In X11 that's indeed what it traditionally does.  In Emacs-22.1 where
I added the --display argument, it indeed worked that way.

> emacs -nw --display $DISPLAY        (opens in tty)
> emacsclient -t --display $DISPLAY   (opens in tty)

Indeed and

  emacs --display $DISPLAY
  emacsclient --display $DISPLAY

should also both use an X11 frame on $DISPLAY.
That fact that the Emacs server does not yet have an X11 connection open
is not taken into account to decide what to: if the client does not
explicitly ask for a tty, then the default is to use an X11 frame.


        Stefan

Re: emacsclient bug

[Richard Stallman]

    That fact that the Emacs server does not yet have an X11 connection open
    is not taken into account to decide what to: if the client does not
    explicitly ask for a tty, then the default is to use an X11 frame.

That might not be the right thing to do.  It seems to me that the most
convenient behavior for emacsclient is to use (by default) the tty or
display that Emacs is already using.  It would do that unless you
specify -display or -nw or -t.

Doesn't that seem right to you?

Re: emacsclient bug

[Stefan Monnier]

>     That fact that the Emacs server does not yet have an X11 connection open
>     is not taken into account to decide what to: if the client does not
>     explicitly ask for a tty, then the default is to use an X11 frame.

> That might not be the right thing to do.  It seems to me that the most
> convenient behavior for emacsclient is to use (by default) the tty or
> display that Emacs is already using.  It would do that unless you
> specify -display or -nw or -t.

> Doesn't that seem right to you?

Yes, I've just changed it, so that now it behaves by default as it used
to in Emacs-22: connection to $DISPLAY is only attempted if it's
explicitly requested by a --display parameter.  It makes the default
not only closer to previous behavior but also "safer" I believe.


        Stefan

Re: emacsclient bug

[Dan Nicolaescu]

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

  > >     That fact that the Emacs server does not yet have an X11 connection open
  > >     is not taken into account to decide what to: if the client does not
  > >     explicitly ask for a tty, then the default is to use an X11 frame.
  > 
  > > That might not be the right thing to do.  It seems to me that the most
  > > convenient behavior for emacsclient is to use (by default) the tty or
  > > display that Emacs is already using.  It would do that unless you
  > > specify -display or -nw or -t.
  > 
  > > Doesn't that seem right to you?
  > 
  > Yes, I've just changed it, so that now it behaves by default as it used
  > to in Emacs-22: connection to $DISPLAY is only attempted if it's
  > explicitly requested by a --display parameter.  It makes the default
  > not only closer to previous behavior but also "safer" I believe.

Does it work? 

After updating from CVS and make bootstrap

emacs -Q -f server-start&

emacsclient ~/.emacs 
just hangs

emacsclient -t ~/.emacs 
works, it opens a tty frame.

Re: emacsclient bug

[Dan Nicolaescu]

Dan Nicolaescu <dann@ics.uci.edu> writes:

  > Stefan Monnier <monnier@iro.umontreal.ca> writes:
  > 
  >   > >     That fact that the Emacs server does not yet have an X11 connection open
  >   > >     is not taken into account to decide what to: if the client does not
  >   > >     explicitly ask for a tty, then the default is to use an X11 frame.
  >   > 
  >   > > That might not be the right thing to do.  It seems to me that the most
  >   > > convenient behavior for emacsclient is to use (by default) the tty or
  >   > > display that Emacs is already using.  It would do that unless you
  >   > > specify -display or -nw or -t.
  >   > 
  >   > > Doesn't that seem right to you?
  >   > 
  >   > Yes, I've just changed it, so that now it behaves by default as it used
  >   > to in Emacs-22: connection to $DISPLAY is only attempted if it's
  >   > explicitly requested by a --display parameter.  It makes the default
  >   > not only closer to previous behavior but also "safer" I believe.
  > 
  > Does it work? 
  > 
  > After updating from CVS and make bootstrap
  > 
  > emacs -Q -f server-start&
  > 
  > emacsclient ~/.emacs 
  > just hangs

I fixed this.

There's still one issue left: "-c" does not work anymore, it creates a
tty frame.

Re: emacsclient bug

[Richard Stallman]

    Yes, I've just changed it, so that now it behaves by default as it used
    to in Emacs-22: connection to $DISPLAY is only attempted if it's
    explicitly requested by a --display parameter.  It makes the default
    not only closer to previous behavior but also "safer" I believe.

Thanks.

Re: emacsclient bug

[KOBAYASHI Yasuhiro]

f
f
d
d
d
d
-- 
KOBAYASHI Yasuhiro <kobayays@gmail.com>

Re: emacsclient bug

[Sascha Wilde]

Dan Nicolaescu <dann@ics.uci.edu> wrote:
> I fixed this.
>
> There's still one issue left: "-c" does not work anymore, it creates a
> tty frame.

emacsclient -d $DISPLAY -c
works, but this is very annoying, because there are many situations
where emacsclient is handy but determining the current display is not so
easy.

For example I use the ViewSourceWith Firefox extension, with emacsclient
as editor and `-c $f' as parameters, ($f is expanded by the plugin).

This stopped working with the new emacsclient version and `-d $DISPLAY
-c $f' doesn't help, because there is no shell involved which could
expand $DISPLAY.

cheers
sascha
-- 
Parents strongly cautioned  --  this  posting  is  intended for mature
audiences  over  18.  It  may  contain some material that many parents
would not find suitable for children and may include intense violence,
sexual situations, coarse language and suggestive dialogue.

Re: emacsclient bug

[David De La Harpe Golden]

On 31/01/2008, Sascha Wilde <wilde@sha-bang.de> wrote:
> This stopped working with the new emacsclient version and `-d $DISPLAY
> -c $f' doesn't help, because there is no shell involved which could
> expand $DISPLAY.
>

But does it it still exist in the process' environment?
Maybe  emacsclient now just needs a -D option for "use X11 display
found in DISPLAY env var" ? So you can do "emacsclient -D -c", say.

If you set the ViewSourceWith editor to dumpenv, where dumpenv is shell script

#!/bin/sh
env >/tmp/myenv

, what does myenv end up containing?  Does it have a DISPLAY or is
firefox cleaning the env of its children?

Re: emacsclient bug

[Leo]

On 2008-01-27 15:41 +0000, Dan Nicolaescu wrote:
>> emacsclient ~/.emacs 
>> just hangs
>
> I fixed this.
>
> There's still one issue left: "-c" does not work anymore, it creates a
> tty frame.

Hope someone fixes this soon!

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: emacsclient bug

[Sascha Wilde]

"David De La Harpe Golden" <david.delaharpe.golden@gmail.com> wrote:

> On 31/01/2008, Sascha Wilde <wilde@sha-bang.de> wrote:
>> This stopped working with the new emacsclient version and `-d $DISPLAY
>> -c $f' doesn't help, because there is no shell involved which could
>> expand $DISPLAY.
>>
>
> But does it it still exist in the process' environment?

Sure it is.  The problem is that the latest changes caused emacsclient
to open a tty frame even with `-c' and a valid DISPLAY in the
environment.

> Maybe  emacsclient now just needs a -D option for "use X11 display
> found in DISPLAY env var" ? So you can do "emacsclient -D -c", say.

emacsclient -D -c
emacsclient: invalid option -- D

emacsclient only knows about -d, which _requires_ an argument of the
form HOST:SERVER or HOST:SERVER.SCREEN.

> or is firefox cleaning the env of its children?

No it doesn't and my setup used to work before the behavior of
emacsclient was changes...

cheers
sascha
-- 
Sascha Wilde
Well, *my* brain likes to think it's vastly more powerful than any
finite Turing machine but it hasn't proven that to me...
  -- Christopher Koppler in comp.lang.lisp

Re: emacsclient bug

[David De La Harpe Golden]

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

On 04/02/2008, Sascha Wilde <wilde@sha-bang.de> wrote:
> emacsclient -D -c
> emacsclient: invalid option -- D
>

Sorry, I was suggesting adding a -D meaning "use display from
$DISPLAY", I know emacsclient doesn't have it.  Very trivial patch to
do this attached.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacsclient-disp-from-env.diff --]
[-- Type: text/x-diff; name=emacsclient-disp-from-env.diff, Size: 2074 bytes --]

Index: emacsclient.c
===================================================================
RCS file: /sources/emacs/emacs/lib-src/emacsclient.c,v
retrieving revision 1.121
diff -U 4 -r1.121 emacsclient.c
--- emacsclient.c	26 Jan 2008 21:27:38 -0000	1.121
+++ emacsclient.c	4 Feb 2008 14:50:22 -0000
@@ -171,8 +171,9 @@
 #endif
   { "server-file",	required_argument, NULL, 'f' },
 #ifndef WINDOWSNT
   { "display",	required_argument, NULL, 'd' },
+  { "this-display", no_argument, NULL, 'D'},
 #endif
   { 0, 0, 0, 0 }
 };
 
@@ -479,24 +480,15 @@
      char **argv;
 {
   alternate_editor = egetenv ("ALTERNATE_EDITOR");
 
-  /* We used to set `display' to $DISPLAY by default, but this changed the
-     default behavior and is sometimes inconvenient.  So instead of forcing
-     users to say "--display ''" when they want to use Emacs's existing tty
-     or display connection, we force them to use "--display $DISPLAY" if
-     they want Emacs to connect to their current display.  */
-#if 0
-  display = egetenv ("DISPLAY");
-#endif
-
   while (1)
     {
       int opt = getopt_long (argc, argv,
 #ifndef NO_SOCKETS_IN_FILE_SYSTEM
-			     "VHnea:s:f:d:tc",
+			     "VHnea:s:f:d:Dtc",
 #else
-			     "VHnea:f:d:tc",
+			     "VHnea:f:d:Dtc",
 #endif
 			     longopts, 0);
 
       if (opt == EOF)
@@ -530,8 +522,11 @@
 #if 1 /* !defined WINDOWS */
 	case 'd':
 	  display = optarg;
 	  break;
+        case 'D':
+	  display = egetenv ("DISPLAY");
+	  break;
 #endif
 
 	case 'n':
 	  nowait = 1;
@@ -612,9 +607,11 @@
 			use the current Emacs frame\n\
 -e, --eval    		Evaluate the FILE arguments as ELisp expressions\n\
 -n, --no-wait		Don't wait for the server to return\n"
 #ifndef WINDOWSNT
-"-d, --display=DISPLAY	Visit the file in the given display\n"
+"-d, --display=DISPLAY	Visit the file in the given X11 display\n"
+"-D, --this-display	Visit the file in current X11 display\n\
+			(found in environment variable $DISPLAY)\n"
 #endif
 #ifndef NO_SOCKETS_IN_FILE_SYSTEM
 "-s, --socket-name=FILENAME\n\
 			Set filename of the UNIX socket for communication\n"

Re: emacsclient bug

[David De La Harpe Golden]

> Sorry, I was suggesting adding a -D

... as a new option to emacsclient, I mean!

Re: emacsclient bug

[Sascha Wilde]

"David De La Harpe Golden" <david.delaharpe.golden@gmail.com> wrote:

>> Sorry, I was suggesting adding a -D
>
> ... as a new option to emacsclient, I mean!

Ah, ok.  I like it then!

cheers
sascha
-- 
Sascha Wilde : "GUIs normally make it simple to accomplish simple 
             : actions and impossible to accomplish complex actions."
             : (Doug Gwyn - 22/Jun/91 in comp.unix.wizards)

Re: emacsclient bug

[Stefan Monnier]

> emacsclient -d $DISPLAY -c
> works, but this is very annoying, because there are many situations
> where emacsclient is handy but determining the current display is not so
> easy.

> For example I use the ViewSourceWith Firefox extension, with emacsclient
> as editor and `-c $f' as parameters, ($f is expanded by the plugin).

How did you do it with Emacs-22?

The -c argument is not very clearly specified: it just says "use a new
frame", so if the current Emacs frame is on a tty, creating a new frame
on that same tty seems like a correct choice.

If you don't want tty frames, then maybe you shouldn't start your Emacs
server on a tty?

Of course, if your Emacs server has both X11 and tty frames, then "-c"
will arbitrarily open either a tty frame or an X11 frame depending on
which frame happens to be selected when the emacsclient connects to it.

Maybe there should be some kind of affinity: look at the emacsclient
context (its tty and its $DISPLAY setting) and then look for an existing
frame (or terminal) that is "similar" (same tty or same $DISPLAY).
This would remove/reduce the "arbitrary" part of the behavior.


        Stefan

Re: emacsclient bug

[Dan Nicolaescu]

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

  > > emacsclient -d $DISPLAY -c
  > > works, but this is very annoying, because there are many situations
  > > where emacsclient is handy but determining the current display is not so
  > > easy.
  > 
  > > For example I use the ViewSourceWith Firefox extension, with emacsclient
  > > as editor and `-c $f' as parameters, ($f is expanded by the plugin).
  > 
  > How did you do it with Emacs-22?
  > 
  > The -c argument is not very clearly specified: it just says "use a new
  > frame", so if the current Emacs frame is on a tty, creating a new frame
  > on that same tty seems like a correct choice.
  > 
  > If you don't want tty frames, then maybe you shouldn't start your Emacs
  > server on a tty?
  > 
  > Of course, if your Emacs server has both X11 and tty frames, then "-c"
  > will arbitrarily open either a tty frame or an X11 frame depending on
  > which frame happens to be selected when the emacsclient connects to it.

Given that, taking into account the current frame when emacsclient
connects does not seem like a good idea.

  > Maybe there should be some kind of affinity: look at the emacsclient
  > context (its tty and its $DISPLAY setting) and then look for an existing
  > frame (or terminal) that is "similar" (same tty or same $DISPLAY).
  > This would remove/reduce the "arbitrary" part of the behavior.

IMO:
  - if -c is given, and $DISPLAY is present in the emacsclient
  environment (-d is not on the command line), then it should be
  equivalent to -c -d $DISPLAY

  - if $DISPLAY is not present, then it should be equivalent to -t

Re: emacsclient bug

[Stefan Monnier]

>> Of course, if your Emacs server has both X11 and tty frames, then "-c"
>> will arbitrarily open either a tty frame or an X11 frame depending on
>> which frame happens to be selected when the emacsclient connects to it.

> Given that, taking into account the current frame when emacsclient
> connects does not seem like a good idea.

Yes, clearly it's not a feature.  It's just the way it works and has
worked for the last many years.  The X11-vs-tty problem is new, but the
same issue was present long before if you have several X11
connections open.

>> Maybe there should be some kind of affinity: look at the emacsclient
>> context (its tty and its $DISPLAY setting) and then look for an existing
>> frame (or terminal) that is "similar" (same tty or same $DISPLAY).
>> This would remove/reduce the "arbitrary" part of the behavior.

> IMO:
>   - if -c is given, and $DISPLAY is present in the emacsclient
>   environment (-d is not on the command line), then it should be
>   equivalent to -c -d $DISPLAY

>   - if $DISPLAY is not present, then it should be equivalent to -t

Hmm... so you're suggesting that "-c" would means something like "open
a new frame just like starting a new Emacs would do"?  I guess that
would make sense.


        Stefan


PS: In any case, I think my "affinity" idea is needed/useful in the
non-"-c" case, so we should implement it anyway.

Re: emacsclient bug

[Richard Stallman]

      > Of course, if your Emacs server has both X11 and tty frames, then "-c"
      > will arbitrarily open either a tty frame or an X11 frame depending on
      > which frame happens to be selected when the emacsclient connects to it.

    Given that, taking into account the current frame when emacsclient
    connects does not seem like a good idea.

I disagree.  I think that what -c does is the right default.
It says "make a new frame".  Making it on the same terminal
is clearly the best default.

You can specify additional options to say where the new frame should go.

Re: emacsclient bug

[Leo]

On 2008-02-07 00:44 +0000, Richard Stallman wrote:
> I disagree.  I think that what -c does is the right default.
> It says "make a new frame".  Making it on the same terminal
> is clearly the best default.

There is already an option to do this i.e. `emacsclient -t'. And if ones
runs `emacsclient -c' from desktop running dialogue (in gnome `Alt +
F2'), what would be a correct behavior?

>
> You can specify additional options to say where the new frame should
>go.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: emacsclient bug

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >       > Of course, if your Emacs server has both X11 and tty frames, then "-c"
  >       > will arbitrarily open either a tty frame or an X11 frame depending on
  >       > which frame happens to be selected when the emacsclient connects to it.
  > 
  >     Given that, taking into account the current frame when emacsclient
  >     connects does not seem like a good idea.
  > 
  > I disagree.  I think that what -c does is the right default.
  > It says "make a new frame".  Making it on the same terminal
  > is clearly the best default.

I think you misunderstood that part, the lines you cited were about
`(current-frame)'. See a few lines below in my original message that I
was saying the same thing that you want.

Re: emacsclient bug

[Sascha Wilde]

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

>> emacsclient -d $DISPLAY -c
>> works, but this is very annoying, because there are many situations
>> where emacsclient is handy but determining the current display is not so
>> easy.
[...]
> How did you do it with Emacs-22?
>
> The -c argument is not very clearly specified: it just says "use a new
> frame", so if the current Emacs frame is on a tty, creating a new frame
> on that same tty seems like a correct choice.
>
> If you don't want tty frames, then maybe you shouldn't start your Emacs
> server on a tty?

I didn't.  The Emacs server is running under X11, with only X11 frames
used, nevertheless `emacsclient -c' always tries to create an tty frame
(and fails if it is not called from an interactive tty).

sascha
-- 
Sascha Wilde
    "Liebet eure Feinde, vielleicht schadet das ihrem Ruf" 
    (Stanislaw Jerzy Lec)

Re: emacsclient bug

[Sascha Wilde]

Richard Stallman <rms@gnu.org> wrote:

>       > Of course, if your Emacs server has both X11 and tty frames, then "-c"
>       > will arbitrarily open either a tty frame or an X11 frame depending on
>       > which frame happens to be selected when the emacsclient connects to it.
>
>     Given that, taking into account the current frame when emacsclient
>     connects does not seem like a good idea.
>
> I disagree.  I think that what -c does is the right default.
> It says "make a new frame".  Making it on the same terminal
> is clearly the best default.
>
> You can specify additional options to say where the new frame should go.

No objections here, but I thought that `-c' would explicitly state "open a
new X11 frame (if available)" in contrast to `-t' which is documented as
"Open a new Emacs frame on the current terminal".

If this isn't supposed to be the case, an option saying: open a new X11
Frame on the current $DISPLAY is needed.  Currently only the combination
of `-c' and `-d' opens an new X11 frame, and `-d' requires an explicitly
given display (which is annoying for the reasons stated in my original
mail).

cheers
sascha
-- 
Sascha Wilde : "GUIs normally make it simple to accomplish simple 
             : actions and impossible to accomplish complex actions."
             : (Doug Gwyn - 22/Jun/91 in comp.unix.wizards)

Re: emacsclient bug

[Sascha Wilde]

Dan Nicolaescu <dann@ics.uci.edu> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> IMO:
>   - if -c is given, and $DISPLAY is present in the emacsclient
>   environment (-d is not on the command line), then it should be
>   equivalent to -c -d $DISPLAY
>
>   - if $DISPLAY is not present, then it should be equivalent to -t

+1

sascha
-- 
Sascha Wilde
Life's too short to read boring signatures

Re: emacsclient bug

[Richard Stallman]

    No objections here, but I thought that `-c' would explicitly state "open a
    new X11 frame (if available)" in contrast to `-t' which is documented as
    "Open a new Emacs frame on the current terminal".

That would also be a consistent definition.

I have no strong preference between your proposed definition
and the definition that the other message cited as the official one.

Re: emacsclient bug

[Stefan Monnier]

>   - if -c is given, and $DISPLAY is present in the emacsclient
>   environment (-d is not on the command line), then it should be
>   equivalent to -c -d $DISPLAY

>   - if $DISPLAY is not present, then it should be equivalent to -t

I've just installed a patch which should make it behave as
described above.


        Stefan

Re: emacsclient bug

[Sascha Wilde]

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

>>   - if -c is given, and $DISPLAY is present in the emacsclient
>>   environment (-d is not on the command line), then it should be
>>   equivalent to -c -d $DISPLAY
>
>>   - if $DISPLAY is not present, then it should be equivalent to -t
>
> I've just installed a patch which should make it behave as
> described above.

Just gave it a try, works like expected again -- thanks!

sascha
-- 
Sascha Wilde 
"If you were young again, would you start writing TeX again or would
you use Microsoft Word, or another word processor?" - "I hope to die
before I *have* to use Microsoft Word."    --  Prof. Donald E. Knuth