* bug#11091: 24.0.94; emacsclient -t
@ 2012-03-25 22:10 Dani Moncayo
2012-03-25 22:29 ` Dani Moncayo
0 siblings, 1 reply; 24+ messages in thread
From: Dani Moncayo @ 2012-03-25 22:10 UTC (permalink / raw)
To: 11091
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
^ permalink raw reply [flat|nested] 24+ messages in thread* bug#11091: 24.0.94; emacsclient -t 2012-03-25 22:10 bug#11091: 24.0.94; emacsclient -t Dani Moncayo @ 2012-03-25 22:29 ` Dani Moncayo 2012-03-25 23:39 ` Juanma Barranquero 0 siblings, 1 reply; 24+ messages in thread From: Dani Moncayo @ 2012-03-25 22:29 UTC (permalink / raw) To: 11091 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-25 22:29 ` Dani Moncayo @ 2012-03-25 23:39 ` Juanma Barranquero 2012-03-25 23:45 ` Juanma Barranquero 0 siblings, 1 reply; 24+ messages in thread From: Juanma Barranquero @ 2012-03-25 23:39 UTC (permalink / raw) To: Dani Moncayo; +Cc: 11091 > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-25 23:39 ` Juanma Barranquero @ 2012-03-25 23:45 ` Juanma Barranquero 2012-03-26 6:40 ` Dani Moncayo 0 siblings, 1 reply; 24+ messages in thread From: Juanma Barranquero @ 2012-03-25 23:45 UTC (permalink / raw) To: Dani Moncayo; +Cc: 11091 > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-25 23:45 ` Juanma Barranquero @ 2012-03-26 6:40 ` Dani Moncayo 2012-03-26 9:19 ` Juanma Barranquero 0 siblings, 1 reply; 24+ messages in thread From: Dani Moncayo @ 2012-03-26 6:40 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 11091 >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-26 6:40 ` Dani Moncayo @ 2012-03-26 9:19 ` Juanma Barranquero 2012-03-26 9:25 ` Dani Moncayo 0 siblings, 1 reply; 24+ messages in thread From: Juanma Barranquero @ 2012-03-26 9:19 UTC (permalink / raw) To: Dani Moncayo; +Cc: 11091 On Mon, Mar 26, 2012 at 08:40, Dani Moncayo <dmoncayo@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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-26 9:19 ` Juanma Barranquero @ 2012-03-26 9:25 ` Dani Moncayo 2012-03-26 9:27 ` Juanma Barranquero 2012-03-26 12:39 ` Stefan Monnier 0 siblings, 2 replies; 24+ messages in thread From: Dani Moncayo @ 2012-03-26 9:25 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 11091 >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-26 9:25 ` Dani Moncayo @ 2012-03-26 9:27 ` Juanma Barranquero 2012-03-26 22:49 ` Dani Moncayo 2012-03-26 12:39 ` Stefan Monnier 1 sibling, 1 reply; 24+ messages in thread From: Juanma Barranquero @ 2012-03-26 9:27 UTC (permalink / raw) To: Dani Moncayo; +Cc: 11091 On Mon, Mar 26, 2012 at 11:25, Dani Moncayo <dmoncayo@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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-26 9:27 ` Juanma Barranquero @ 2012-03-26 22:49 ` Dani Moncayo 2012-03-31 9:54 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Dani Moncayo @ 2012-03-26 22:49 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 11091 >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-26 22:49 ` Dani Moncayo @ 2012-03-31 9:54 ` Eli Zaretskii 2012-03-31 11:38 ` Dani Moncayo 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2012-03-31 9:54 UTC (permalink / raw) To: Dani Moncayo; +Cc: lekktu, 11091-done > Date: Tue, 27 Mar 2012 00:49:02 +0200 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: 11091@debbugs.gnu.org, Eli Zaretskii <eliz@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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-31 9:54 ` Eli Zaretskii @ 2012-03-31 11:38 ` Dani Moncayo 2012-03-31 11:45 ` Dani Moncayo 2012-03-31 12:34 ` Eli Zaretskii 0 siblings, 2 replies; 24+ messages in thread From: Dani Moncayo @ 2012-03-31 11:38 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 11091 >> >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-31 11:38 ` Dani Moncayo @ 2012-03-31 11:45 ` Dani Moncayo 2012-04-11 16:40 ` Glenn Morris 2012-03-31 12:34 ` Eli Zaretskii 1 sibling, 1 reply; 24+ messages in thread From: Dani Moncayo @ 2012-03-31 11:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 11091 >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-31 11:45 ` Dani Moncayo @ 2012-04-11 16:40 ` Glenn Morris 2012-04-11 19:53 ` Dani Moncayo 0 siblings, 1 reply; 24+ messages in thread From: Glenn Morris @ 2012-04-11 16:40 UTC (permalink / raw) To: Dani Moncayo; +Cc: 11091 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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-04-11 16:40 ` Glenn Morris @ 2012-04-11 19:53 ` Dani Moncayo 0 siblings, 0 replies; 24+ messages in thread From: Dani Moncayo @ 2012-04-11 19:53 UTC (permalink / raw) To: Glenn Morris; +Cc: 11091 > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-31 11:38 ` Dani Moncayo 2012-03-31 11:45 ` Dani Moncayo @ 2012-03-31 12:34 ` Eli Zaretskii 2012-04-01 8:44 ` Dani Moncayo 1 sibling, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2012-03-31 12:34 UTC (permalink / raw) To: Dani Moncayo; +Cc: lekktu, 11091 > Date: Sat, 31 Mar 2012 13:38:25 +0200 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: lekktu@gmail.com, 11091@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? ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-31 12:34 ` Eli Zaretskii @ 2012-04-01 8:44 ` Dani Moncayo 2012-04-01 17:13 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Dani Moncayo @ 2012-04-01 8:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 11091 >> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-04-01 8:44 ` Dani Moncayo @ 2012-04-01 17:13 ` Eli Zaretskii 2012-04-01 19:17 ` Dani Moncayo 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2012-04-01 17:13 UTC (permalink / raw) To: Dani Moncayo; +Cc: lekktu, 11091 > Date: Sun, 1 Apr 2012 10:44:35 +0200 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: lekktu@gmail.com, 11091@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 :-) ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-04-01 17:13 ` Eli Zaretskii @ 2012-04-01 19:17 ` Dani Moncayo 2012-04-01 20:49 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Dani Moncayo @ 2012-04-01 19:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 11091 > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-04-01 19:17 ` Dani Moncayo @ 2012-04-01 20:49 ` Eli Zaretskii 2012-04-02 7:01 ` Dani Moncayo 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2012-04-01 20:49 UTC (permalink / raw) To: Dani Moncayo; +Cc: lekktu, 11091 > Date: Sun, 1 Apr 2012 21:17:58 +0200 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: lekktu@gmail.com, 11091@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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-04-01 20:49 ` Eli Zaretskii @ 2012-04-02 7:01 ` Dani Moncayo 2012-04-02 17:36 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Dani Moncayo @ 2012-04-02 7:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: lekktu, 11091 >> > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-04-02 7:01 ` Dani Moncayo @ 2012-04-02 17:36 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2012-04-02 17:36 UTC (permalink / raw) To: Dani Moncayo; +Cc: lekktu, 11091 > Date: Mon, 2 Apr 2012 09:01:26 +0200 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: lekktu@gmail.com, 11091@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. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-26 9:25 ` Dani Moncayo 2012-03-26 9:27 ` Juanma Barranquero @ 2012-03-26 12:39 ` Stefan Monnier 2012-03-26 14:03 ` Juanma Barranquero 2012-03-26 19:15 ` Eli Zaretskii 1 sibling, 2 replies; 24+ messages in thread From: Stefan Monnier @ 2012-03-26 12:39 UTC (permalink / raw) To: Dani Moncayo; +Cc: Juanma Barranquero, 11091 >>> 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-26 12:39 ` Stefan Monnier @ 2012-03-26 14:03 ` Juanma Barranquero 2012-03-26 19:15 ` Eli Zaretskii 1 sibling, 0 replies; 24+ messages in thread From: Juanma Barranquero @ 2012-03-26 14:03 UTC (permalink / raw) To: Stefan Monnier; +Cc: 11091 On Mon, Mar 26, 2012 at 14:39, Stefan Monnier <monnier@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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#11091: 24.0.94; emacsclient -t 2012-03-26 12:39 ` Stefan Monnier 2012-03-26 14:03 ` Juanma Barranquero @ 2012-03-26 19:15 ` Eli Zaretskii 1 sibling, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2012-03-26 19:15 UTC (permalink / raw) To: Stefan Monnier; +Cc: lekktu, 11091 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Mon, 26 Mar 2012 08:39:02 -0400 > Cc: Juanma Barranquero <lekktu@gmail.com>, 11091@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. ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2012-04-11 19:53 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-03-25 22:10 bug#11091: 24.0.94; emacsclient -t Dani Moncayo 2012-03-25 22:29 ` Dani Moncayo 2012-03-25 23:39 ` Juanma Barranquero 2012-03-25 23:45 ` Juanma Barranquero 2012-03-26 6:40 ` Dani Moncayo 2012-03-26 9:19 ` Juanma Barranquero 2012-03-26 9:25 ` Dani Moncayo 2012-03-26 9:27 ` Juanma Barranquero 2012-03-26 22:49 ` Dani Moncayo 2012-03-31 9:54 ` Eli Zaretskii 2012-03-31 11:38 ` Dani Moncayo 2012-03-31 11:45 ` Dani Moncayo 2012-04-11 16:40 ` Glenn Morris 2012-04-11 19:53 ` Dani Moncayo 2012-03-31 12:34 ` Eli Zaretskii 2012-04-01 8:44 ` Dani Moncayo 2012-04-01 17:13 ` Eli Zaretskii 2012-04-01 19:17 ` Dani Moncayo 2012-04-01 20:49 ` Eli Zaretskii 2012-04-02 7:01 ` Dani Moncayo 2012-04-02 17:36 ` Eli Zaretskii 2012-03-26 12:39 ` Stefan Monnier 2012-03-26 14:03 ` Juanma Barranquero 2012-03-26 19:15 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).