GNU bug report logs - #11091
24.0.94; emacsclient -t

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11091 in the body.
You can then email your comments to 11091 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 00:10:43 +0200

Hello,

From a cmd.exe terminal:
* emacs -Q
* M-x server-start RET

Then, from another cmd.exe terminal:
* emacsclient -t some-file

According to the manual [1], the expected behavior would be to open
"some-file" in a new frame inside the second terminal, but I see that
a new graphical frame is created instead.

Also, if I repeat the experiment starting with "emacs -Q -nw", the
effect is that a new frame is created in the first terminal, when TRT
would be to create the frame in the second terminal.


--- Footnotes ------

[1] Quotation from (info "(emacs) emacsclient Options")

  `-t'
  `--tty'
  `-nw'
       Create a new Emacs frame on the current text-only terminal,
       instead of using an existing Emacs frame.  Emacs can open a
       text-only terminal even if it was started in another text-only
       terminal, or on a graphical display.  If you omit a filename
       argument while supplying this option, the new frame displays the
       `*scratch*' buffer.  *Note Buffers::.


In GNU Emacs 24.0.94.1 (i386-mingw-nt6.1.7601)
 of 2012-03-23 on DANI-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -IC:/emacs/libs/giflib-4.1.4-1/include
 -IC:/emacs/libs/gnutls-3.0.16/include -IC:/emacs/libs/jpeg-6b-4/include
 -IC:/emacs/libs/libpng-1.4.10 -IC:/emacs/libs/libxpm-3.5.8/include
 -IC:/emacs/libs/libxpm-3.5.8/src -IC:/emacs/libs/tiff-3.8.2-1/include
 -IC:/emacs/libs/zlib-1.2.6'


-- 
Dani Moncayo

Message #8 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 00:29:37 +0200

Here is another similar misbehavior, but this time with the "-c" option:

From a cmd.exe terminal:
* emacs -Q -nw
* M-x server-start RET

Then, from another cmd.exe terminal:
* emacsclient -c some-file

Here TRT would be to open the file in a new graphical frame [1], but I
observe that the new frame is created in the original terminal
instead.


--- Footnotes -----

[1] Quotation from (info "(emacs)emacsclient Options"):

  `-c'
       Create a new graphical frame, instead of using an existing Emacs
       frame.  Emacs can create a graphical frame even if it was started
       in a text-only terminal, provided it is able to connect to a
       graphical display.  [...]

-- 
Dani Moncayo

Message #11 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 01:39:51 +0200

> Here is another similar misbehavior, but this time with the "-c" option:

Neither case is a misbehavior. Both are a consequence of the fact that
Emacs on Windows does not support simulanteously GUI and tty frames in
the same instance. So -t and -c create GUI frames in GUI Emacs, and
console frames in a console Emacs.

    Juanma

Message #14 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 01:45:30 +0200

> Neither case is a misbehavior. Both are a consequence of the fact that
> Emacs on Windows does not support simulanteously GUI and tty frames in
> the same instance.

Also, on Windows one process can be associated with only one console.
So there's no way to open a -nw Emacs in one cmd.exe and make it
create frames in another cmd's window.

    Juanma

Message #17 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 08:40:53 +0200

>> Neither case is a misbehavior. Both are a consequence of the fact that
>> Emacs on Windows does not support simulanteously GUI and tty frames in
>> the same instance.
>
> Also, on Windows one process can be associated with only one console.
> So there's no way to open a -nw Emacs in one cmd.exe and make it
> create frames in another cmd's window.

Ok, gracias Juanma.

I think that these limitations are not documented in the manual.  If
so, could this be fixed, please?

TIA.

-- 
Dani Moncayo

Message #20 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 11:19:43 +0200

On Mon, Mar 26, 2012 at 08:40, Dani Moncayo <dmoncayo <at> gmail.com> wrote:

> I think that these limitations are not documented in the manual.  If
> so, could this be fixed, please?

I'm not sure the manual is the right place to document such limitations. Eli?

    Juanma

Message #23 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 11:25:45 +0200

>> I think that these limitations are not documented in the manual.  If
>> so, could this be fixed, please?
>
> I'm not sure the manual is the right place to document such limitations. Eli?

Why not?

The manual currently has many of such explanations, e.g., in that same
info node "(emacs)emacsclient Options":

  `-s SERVER-NAME'
  `--socket-name=SERVER-NAME'
       Connect to the Emacs server named SERVER-NAME.  The server name is
       given by the variable `server-name' on the Emacs server.  If this
       option is omitted, `emacsclient' connects to the first server it
       finds.  (This option is not supported on MS-Windows.)


-- 
Dani Moncayo

Message #26 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 11:27:22 +0200

On Mon, Mar 26, 2012 at 11:25, Dani Moncayo <dmoncayo <at> gmail.com> wrote:

> The manual currently has many of such explanations, e.g., in that same
> info node "(emacs)emacsclient Options":

You're right. Could you please send a patch?

    Juanma

Message #29 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 08:39:02 -0400

>>> I think that these limitations are not documented in the manual.  If
>>> so, could this be fixed, please?
>> I'm not sure the manual is the right place to document such
>> limitations. Eli?
> Why not?

While we could put it in the manual, I think it'll be more useful to
users if we can emit a warning when emacsclient requests something we
can't do (e.g. open a tty frame when we're running in the Windows GUI).


        Stefan

Message #32 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 11091 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 16:03:09 +0200

On Mon, Mar 26, 2012 at 14:39, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:

> While we could put it in the manual, I think it'll be more useful to
> users if we can emit a warning when emacsclient requests something we
> can't do (e.g. open a tty frame when we're running in the Windows GUI).

The reason we unified -t and -c in the Windows' emacsclient is because
the user can then invoke emacslient -(c|t) from a shortcut or .CMD
file and not have to worry about the Emacs server instance being GUI
or console. The user already has an Emacs server running (or the call
to emacsclient will fail for other reasons, unrelated to c/t).
Emitting a warning in these cases seems to me more noisy than helpful.

    Juanma

Message #35 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 26 Mar 2012 15:15:27 -0400

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Mon, 26 Mar 2012 08:39:02 -0400
> Cc: Juanma Barranquero <lekktu <at> gmail.com>, 11091 <at> debbugs.gnu.org
> 
> >>> I think that these limitations are not documented in the manual.  If
> >>> so, could this be fixed, please?
> >> I'm not sure the manual is the right place to document such
> >> limitations. Eli?
> > Why not?
> 
> While we could put it in the manual, I think it'll be more useful to
> users if we can emit a warning when emacsclient requests something we
> can't do (e.g. open a tty frame when we're running in the Windows GUI).

Since this warning will be emitted as part of routine operation, I
think it will be an annoyance.

Message #38 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Tue, 27 Mar 2012 00:49:02 +0200

>> The manual currently has many of such explanations, e.g., in that same
>> info node "(emacs)emacsclient Options":
>
> You're right. Could you please send a patch?

What about this one?

=== modified file 'doc/emacs/misc.texi'
--- doc/emacs/misc.texi 2012-01-19 07:21:25 +0000
+++ doc/emacs/misc.texi 2012-03-26 22:43:36 +0000
@@ -1503,13 +1503,16 @@
 precedence.

 @item -c
-Create a new graphical frame, instead of using an existing Emacs
-frame.  Emacs can create a graphical frame even if it was started in a
-text-only terminal, provided it is able to connect to a graphical
-display.  If no graphical display is available, Emacs creates a new
-text-only terminal frame (@pxref{Frames}).  If you omit a filename
-argument while supplying the @samp{-c} option, the new frame displays
-the @samp{*scratch*} buffer (@pxref{Buffers}).
+Create a new graphical frame if possible, instead of using an existing
+Emacs frame (@pxref{Frames}).  If no graphical display is available,
+Emacs creates a new text-only terminal frame.
+
+On MS-Windows, if the server is on a text-only terminal, it's not
+possible to create a new frame outside that terminal, so a new
+text-only frame is created there.
+
+If you omit a filename argument while supplying the @samp{-c} option,
+the new frame displays the @samp{*scratch*} buffer (@pxref{Buffers}).

 @item -F @var{alist}
 @itemx --frame-parameters=@var{alist}
@@ -1592,11 +1595,15 @@
 @itemx --tty
 @itemx -nw
 Create a new Emacs frame on the current text-only terminal, instead of
-using an existing Emacs frame.  Emacs can open a text-only terminal
-even if it was started in another text-only terminal, or on a
-graphical display.  If you omit a filename argument while supplying
-this option, the new frame displays the @samp{*scratch*} buffer.
-@xref{Buffers}.
+using an existing Emacs frame.
+
+This is not possible on MS-Windows.  So, if the server is on a
+graphical frame, a new graphical frame is created, and if the server
+is on a text-only terminal, a new text-only frame is created in that
+terminal.
+
+If you omit a filename argument while supplying this option, the new
+frame displays the @samp{*scratch*} buffer (@pxref{Buffers}).
 @end table

   If you type @kbd{C-x C-c} (@code{save-buffers-kill-terminal}) in an



-- 
Dani Moncayo

Message #43 received at 11091-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: lekktu <at> gmail.com, 11091-done <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Sat, 31 Mar 2012 12:54:10 +0300

> Date: Tue, 27 Mar 2012 00:49:02 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: 11091 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> 
> >> The manual currently has many of such explanations, e.g., in that same
> >> info node "(emacs)emacsclient Options":
> >
> > You're right. Could you please send a patch?
> 
> What about this one?

Thanks, I committed a slightly different description (trunk revision
107710), and I'm closing this bug.

Message #46 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Sat, 31 Mar 2012 13:38:25 +0200

>> >> The manual currently has many of such explanations, e.g., in that same
>> >> info node "(emacs)emacsclient Options":
>> >
>> > You're right. Could you please send a patch?
>>
>> What about this one?
>
> Thanks, I committed a slightly different description (trunk revision
> 107710), and I'm closing this bug.

Thanks Eli.

Allow me a few comments.

On the "-c" option:

> [...] Emacs can create a graphical frame even if it was started in a
> text-only terminal, provided it is able to connect to a graphical
> display, and provided it can create graphical frames when started
> from a text-only terminal.

Isn't this wording a bit awkward?  "Emacs can do X, provided it is
able to do Y, and provided it can do X"


On the "-t" option:

> Create a new Emacs frame on the current text-only terminal, instead
> of using an existing Emacs frame.  If Emacs can open a text-only
> terminal even if it was started in another text-only terminal, or on
> a graphical display, it will create a text-only frame on the current
> terminal.

That is, "Do X instead of Y.  If Emacs can do X even if Z, it will do
X.".  Not much clean, IMHO.

> Otherwise(2), it will create a new frame, either GUI or text-only,
> on the same terminal where Emacs was started.

Here the last part ("on the same terminal where...") gives the
impression that the new frame will be created on a terminal,
regardless of whether it is GUI or text-only.

Also, in the case that the new frame is text-only, it's not clear
whether the frame will be created in the current terminal one or in
the server one.


-- 
Dani Moncayo

Message #49 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Sat, 31 Mar 2012 13:45:12 +0200

>> Otherwise(2), it will create a new frame, either GUI or text-only,
>> on the same terminal where Emacs was started.
>
> Also, in the case that the new frame is text-only, it's not clear
> whether the frame will be created in the current terminal one or in
> the server one.

Sorry, forget about this comment.  It's obviously wrong.

-- 
Dani Moncayo

Message #52 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Sat, 31 Mar 2012 15:34:12 +0300

> Date: Sat, 31 Mar 2012 13:38:25 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
> 
> Allow me a few comments.

Thanks.

> On the "-c" option:
> 
> > [...] Emacs can create a graphical frame even if it was started in a
> > text-only terminal, provided it is able to connect to a graphical
> > display, and provided it can create graphical frames when started
> > from a text-only terminal.
> 
> Isn't this wording a bit awkward?  "Emacs can do X, provided it is
> able to do Y, and provided it can do X"

I don't see anything awkward here.  Using only one "provided that"
would produce an ambiguous sentence, so I used it twice.

> On the "-t" option:
> 
> > Create a new Emacs frame on the current text-only terminal, instead
> > of using an existing Emacs frame.  If Emacs can open a text-only
> > terminal even if it was started in another text-only terminal, or on
> > a graphical display, it will create a text-only frame on the current
> > terminal.
> 
> That is, "Do X instead of Y.  If Emacs can do X even if Z, it will do
> X.".  Not much clean, IMHO.

The second "X" is not really a literal "X", it uses different
wording.  I see no problem.

> > Otherwise(2), it will create a new frame, either GUI or text-only,
> > on the same terminal where Emacs was started.
> 
> Here the last part ("on the same terminal where...") gives the
> impression that the new frame will be created on a terminal,
> regardless of whether it is GUI or text-only.

"Terminal" is used here in its Emacs sense, and you seem to think
about something slightly different.

> Also, in the case that the new frame is text-only, it's not clear
> whether the frame will be created in the current terminal one or in
> the server one.

The text clearly says "on the same terminal where _Emacs_ was
started".  What is unclear about that?

Message #55 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Sun, 1 Apr 2012 10:44:35 +0200

>> Allow me a few comments.
>> On the "-c" option:
>>
>> > [...] Emacs can create a graphical frame even if it was started in a
>> > text-only terminal, provided it is able to connect to a graphical
>> > display, and provided it can create graphical frames when started
>> > from a text-only terminal.
>>
>> Isn't this wording a bit awkward?  "Emacs can do X, provided it is
>> able to do Y, and provided it can do X"
>
> I don't see anything awkward here.  Using only one "provided that"
> would produce an ambiguous sentence, so I used it twice.

The problem are not the two "provided that", but having "X" as a
prerequisite for itself.

>> On the "-t" option:
>>
>> > Create a new Emacs frame on the current text-only terminal, instead
>> > of using an existing Emacs frame.  If Emacs can open a text-only
>> > terminal even if it was started in another text-only terminal, or on
>> > a graphical display, it will create a text-only frame on the current
>> > terminal.
>>
>> That is, "Do X instead of Y.  If Emacs can do X even if Z, it will do
>> X.".  Not much clean, IMHO.
>
> The second "X" is not really a literal "X", it uses different
> wording.  I see no problem.

The second sentence of this paragraph is IMO too long (not easy to parse).

>> > Otherwise(2), it will create a new frame, either GUI or text-only,
>> > on the same terminal where Emacs was started.
>>
>> Here the last part ("on the same terminal where...") gives the
>> impression that the new frame will be created on a terminal,
>> regardless of whether it is GUI or text-only.
>
> "Terminal" is used here in its Emacs sense, and you seem to think
> about something slightly different.

I think of "terminal" as a shell program designed to interact with the
system using a text-only command-oriented interface.  So far I've not
seen in the manual other meanings for this.  So, saying that a
graphical Emacs frame will be created on a terminal marks no sense to
me, but I can be wrong, of course.


In short: I prefer my version of the doc fix because, IMHO, it is more
clean and easier to parse.  But if you disagree, I'll be ok with the
current one.

Thanks.

-- 
Dani Moncayo

Message #58 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Sun, 01 Apr 2012 20:13:56 +0300

> Date: Sun, 1 Apr 2012 10:44:35 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
> 
> >> > [...] Emacs can create a graphical frame even if it was started in a
> >> > text-only terminal, provided it is able to connect to a graphical
> >> > display, and provided it can create graphical frames when started
> >> > from a text-only terminal.
> >>
> >> Isn't this wording a bit awkward?  "Emacs can do X, provided it is
> >> able to do Y, and provided it can do X"
> >
> > I don't see anything awkward here.  Using only one "provided that"
> > would produce an ambiguous sentence, so I used it twice.
> 
> The problem are not the two "provided that", but having "X" as a
> prerequisite for itself.

Is this better?

  @item -c
  Create a new graphical frame, instead of using an existing Emacs
  frame.  Emacs can create a graphical frame even if it was started in a
  text-only terminal, provided it is able to connect to a graphical
  display.  If it is unable to connect to a graphical display, and on
  systems, such as MS-Windows, where it cannot create graphical frames
  when started from a text-only terminal, Emacs creates a new text-only
  terminal frame (@pxref{Frames}).  If you omit a filename argument
  while supplying the @samp{-c} option, the new frame displays the
  @samp{*scratch*} buffer (@pxref{Buffers}).

> >> On the "-t" option:
> >>
> >> > Create a new Emacs frame on the current text-only terminal, instead
> >> > of using an existing Emacs frame.  If Emacs can open a text-only
> >> > terminal even if it was started in another text-only terminal, or on
> >> > a graphical display, it will create a text-only frame on the current
> >> > terminal.
> >>
> >> That is, "Do X instead of Y.  If Emacs can do X even if Z, it will do
> >> X.".  Not much clean, IMHO.
> >
> > The second "X" is not really a literal "X", it uses different
> > wording.  I see no problem.
> 
> The second sentence of this paragraph is IMO too long (not easy to parse).

How about this?

  @item -t
  @itemx --tty
  @itemx -nw
  Create a new Emacs frame on the current text-only terminal, instead of
  using an existing Emacs frame.  Emacs can open a text-only terminal
  even if it was started in another text-only terminal, or on a
  graphical display.  On systems, such as MS-Windows, where this is
  impossible, Emacs will create a new frame, either GUI or text-only, on
  the same display where it was started.  If you omit a filename
  argument while supplying this option, the new frame displays the
  @samp{*scratch*} buffer.  @xref{Buffers}.

> >> Here the last part ("on the same terminal where...") gives the
> >> impression that the new frame will be created on a terminal,
> >> regardless of whether it is GUI or text-only.
> >
> > "Terminal" is used here in its Emacs sense, and you seem to think
> > about something slightly different.
> 
> I think of "terminal" as a shell program designed to interact with the
> system using a text-only command-oriented interface.  So far I've not
> seen in the manual other meanings for this.  So, saying that a
> graphical Emacs frame will be created on a terminal marks no sense to
> me, but I can be wrong, of course.

I tried to fix that as well, see above.

> In short: I prefer my version of the doc fix

:-)

Message #61 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Sun, 1 Apr 2012 21:17:58 +0200

> Is this better?

I think so.

>  @item -c
>  Create a new graphical frame, instead of using an existing Emacs
>  frame.  Emacs can create a graphical frame even if it was started in a
>  text-only terminal, provided it is able to connect to a graphical
>  display.

ok.

> If it is unable to connect to a graphical display, and on
>  systems, such as MS-Windows, where it cannot create graphical frames
>  when started from a text-only terminal, Emacs creates a new text-only
>  terminal frame (@pxref{Frames}).

It's unclear from that in which terminal will be created the new
text-only frame (whether on the current one or on the server one).

>  If you omit a filename argument
>  while supplying the @samp{-c} option, the new frame displays the
>  @samp{*scratch*} buffer (@pxref{Buffers}).
>
>> >> On the "-t" option:
>> >>
>> >> > Create a new Emacs frame on the current text-only terminal, instead
>> >> > of using an existing Emacs frame.  If Emacs can open a text-only
>> >> > terminal even if it was started in another text-only terminal, or on
>> >> > a graphical display, it will create a text-only frame on the current
>> >> > terminal.
>> >>
>> >> That is, "Do X instead of Y.  If Emacs can do X even if Z, it will do
>> >> X.".  Not much clean, IMHO.
>> >
>> > The second "X" is not really a literal "X", it uses different
>> > wording.  I see no problem.
>>
>> The second sentence of this paragraph is IMO too long (not easy to parse).
>
> How about this?
>
>  @item -t
>  @itemx --tty
>  @itemx -nw
>  Create a new Emacs frame on the current text-only terminal, instead of
>  using an existing Emacs frame.  Emacs can open a text-only terminal
>  even if it was started in another text-only terminal, or on a
>  graphical display.  On systems, such as MS-Windows, where this is
>  impossible, Emacs will create a new frame, either GUI or text-only, on
>  the same display where it was started.  If you omit a filename
>  argument while supplying this option, the new frame displays the
>  @samp{*scratch*} buffer.  @xref{Buffers}.

ok.

>> In short: I prefer my version of the doc fix
>
> :-)

:(  I still wonder what was wrong with my version.  But never mind.
Thanks for your work on Emacs.


-- 
Dani Moncayo

Message #64 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Sun, 01 Apr 2012 23:49:30 +0300

> Date: Sun, 1 Apr 2012 21:17:58 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
> 
> > If it is unable to connect to a graphical display, and on
> >  systems, such as MS-Windows, where it cannot create graphical frames
> >  when started from a text-only terminal, Emacs creates a new text-only
> >  terminal frame (@pxref{Frames}).
> 
> It's unclear from that in which terminal will be created the new
> text-only frame (whether on the current one or on the server one).

I added "on the same terminal where it was started".

> :(  I still wonder what was wrong with my version.

It was too wordy.

> Thanks for your work on Emacs.

Thanks for helping me clarify the text.

Message #67 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 2 Apr 2012 09:01:26 +0200

>> > If it is unable to connect to a graphical display, and on
>> >  systems, such as MS-Windows, where it cannot create graphical frames
>> >  when started from a text-only terminal, Emacs creates a new text-only
>> >  terminal frame (@pxref{Frames}).
>>
>> It's unclear from that in which terminal will be created the new
>> text-only frame (whether on the current one or on the server one).
>
> I added "on the same terminal where it was started".

Sorry but, IIUC, that is correct only on MS-Windows, No?  i.e., on
other systems like GNU/Linux (if there's no graphical display
available) the new text-only frame will be created on the current
terminal.

If I'm right, the above paragraph would need yet another tweak.

>> :(  I still wonder what was wrong with my version.
>
> It was too wordy.

I disagree :).  IMHO my version explained all the corner cases in a
clearer an shorter way.  But as I said I respect your criterion, as
your experience and knowledge in far higher than mine.

Thanks.

-- 
Dani Moncayo

Message #70 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Mon, 02 Apr 2012 20:36:01 +0300

> Date: Mon, 2 Apr 2012 09:01:26 +0200
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: lekktu <at> gmail.com, 11091 <at> debbugs.gnu.org
> 
> >> > If it is unable to connect to a graphical display, and on
> >> >  systems, such as MS-Windows, where it cannot create graphical frames
> >> >  when started from a text-only terminal, Emacs creates a new text-only
> >> >  terminal frame (@pxref{Frames}).
> >>
> >> It's unclear from that in which terminal will be created the new
> >> text-only frame (whether on the current one or on the server one).
> >
> > I added "on the same terminal where it was started".
> 
> Sorry but, IIUC, that is correct only on MS-Windows, No?  i.e., on
> other systems like GNU/Linux (if there's no graphical display
> available) the new text-only frame will be created on the current
> terminal.

Good point.  So I removed that addition, and added some details about
this in the Windows-specific appendix section.

Message #73 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Wed, 11 Apr 2012 12:40:16 -0400

We have a couple of changes from you in Emacs now, and should probably
get an FSF copyright assignment. Is that something you are willing to
do? The process is straightforward, I can send you the form to get
started if you like.

Message #76 received at 11091 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 11091 <at> debbugs.gnu.org
Subject: Re: bug#11091: 24.0.94; emacsclient -t
Date: Wed, 11 Apr 2012 21:53:32 +0200

> We have a couple of changes from you in Emacs now, and should probably
> get an FSF copyright assignment.

So far my changes in Emacs are both trivial and tiny.

> Is that something you are willing to
> do?

Yes, if you deem it necessary.

> The process is straightforward, I can send you the form to get
> started if you like.

Ok.  Thanks.

-- 
Dani Moncayo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.