GNU bug report logs - #25547
25.1.91; emacsclient -c creates frames on the wrong display

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 25547 in the body.
You can then email your comments to 25547 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: Alex Hutcheson <alexhutcheson <at> google.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1.91; emacsclient -c creates frames on the wrong display
Date: Thu, 26 Jan 2017 13:09:46 -0500

When an emacsclient running in a terminal is connected to an Emacs
instance running in a graphical environment, running `emacsclient -c'
from a comint buffer (such as M-x shell) creates a frame in the
graphical environment, where it may be inaccessible to the user who
ran the command.

To reproduce:
1. Run `emacs --daemon' on a system with a graphical display.
2. Login to the system using a terminal with no graphical display. You
   could do this by switching to another virtual terminal (Ctrl-Alt-F1
   works on Ubuntu), or SSH in from another machine.
3. Run `emacsclient -c' or `emacsclient -t' in the terminal to connect
   to the running Emacs instance.
4. Inside Emacs, run M-x shell.
5. In the M-x shell buffer, run `emacsclient -c'.

Ideal behavior: emacsclient creates a frame on the current terminal.
Actual behavior: emacsclient creates a graphical frame in the
  environment in which it was launched, which is inaccessible from the
  terminal.

Possible questions:

Q : Why would you want to run emacsclient from within M-x shell? Why
    not just do whatever you want to do in the frame you already have
    open?
A : Normally the user isn't launching emacsclient directly. Instead,
    a script might be launching emacsclient as part of a larger
    workflow.

Q : Why not just launch emacsclient without the '-c' option?
A : Without the -c flag, emacsclient works well to edit a file or
    series of files, but it doesn't support more complicated tasks.
    For example, a script might want to launch an ediff session, and
    wait until the ediff session exits. The easiest way to do this is
    to use `emacsclient -c' and wait for the connection to be closed.


In GNU Emacs 25.1.91.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars),  
modified by Debian
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu 14.04 LTS

Configured using:
 'configure --build x86_64-linux-gnu --build x86_64-linux-gnu
 --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
  
--enable-locallisppath=/etc/google-emacs:/etc/emacs:/usr/local/share/emacs/25.1.91+gg1+2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1.91+gg1+2/site-lisp:/usr/share/emacs/site-lisp
 --with-crt-dir=/usr/lib/x86_64-linux-gnu --disable-build-details
 --disable-silent-rules --with-modules GOOGLE_VERSION=25.1.91+gg1+2
 --with-x=yes --with-x-toolkit=lucid --with-toolkit-scroll-bars
 --without-gconf --without-gsettings build_alias=x86_64-linux-gnu
 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
 -Werror=format-security -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions
 -Wl,-z,relro -Wl,-fuse-ld=gold,--export-dynamic-symbol=__google_auxv'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -DGOOGLE_EMACS_DEFINE_AUXV''

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS NOTIFY
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Message

Minor modes in effect:
  mml-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  auto-fill-function: message-do-auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Recent messages:
Sending...
Mark set
Fix continuation lines? (y or n) y [59 times]
Mark set
Sending via mail...
if: Mail headers not found
Mark set
Sending...
Mark set [2 times]
Sending via mail...
if: Mail headers not found

Load-path shadows:
None found.

Features:
(pp shadow sort mail-extr emacsbug message format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
google-sendgmr sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils novice cl-extra help-fns help-mode easymenu misearch
multi-isearch dired-aux cl-loaddefs pcase cl-lib dired time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 111409 15495)
 (symbols 48 20120 0)
 (miscs 40 211 363)
 (strings 32 15788 3029)
 (string-bytes 1 498060)
 (vectors 16 12877)
 (vector-slots 8 445607 5773)
 (floats 8 175 297)
 (intervals 56 4381 159)
 (buffers 976 29)
 (heap 1024 34656 1309))

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alex Hutcheson <alexhutcheson <at> google.com>
Cc: 25547 <at> debbugs.gnu.org, Eliza Velasquez <exv <at> google.com>
Subject: Re: bug#25547: 25.1.91; emacsclient -c creates frames on the wrong
 display
Date: Mon, 02 Nov 2020 17:37:53 -0500

> To reproduce:
> 1. Run `emacs --daemon' on a system with a graphical display.
> 2. Login to the system using a terminal with no graphical display. You
>    could do this by switching to another virtual terminal (Ctrl-Alt-F1
>    works on Ubuntu), or SSH in from another machine.
> 3. Run `emacsclient -c' or `emacsclient -t' in the terminal to connect
>    to the running Emacs instance.
> 4. Inside Emacs, run M-x shell.
> 5. In the M-x shell buffer, run `emacsclient -c'.
>
> Ideal behavior: emacsclient creates a frame on the current terminal.
> Actual behavior: emacsclient creates a graphical frame in the
>   environment in which it was launched, which is inaccessible from the
>   terminal.

Indeed the current behavior is a bummer.

The second emacsclient runs within a shell process which itself is
associated to the *shell* buffer, which can be displayed in several
windows, including some of them in the GUI.

So in the above case you actually would like to open the emacsclient
wherever `selected-frame` is (because it's generally impossible to walk
out way back from the second emacsclient process to the parent tty in
which the first emacsclient has opened a frame).

Have you tried using `emacsclient` without the `-c` option (you'll have
to provide a file-name in that case)?


        Stefan

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

From: Eliza Velasquez <exv <at> google.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>
Subject: Re: bug#25547: 25.1.91;
 emacsclient -c creates frames on the wrong display
Date: Mon, 2 Nov 2020 16:34:39 -0800

> Have you tried using `emacsclient` without the `-c` option (you'll have
> to provide a file-name in that case)?

Yeah, that's what our golang wrapper was created to do. It would
detect edge cases like this and instead of invoking emacsclient with
-c, it would run elisp code to create a new frame. But that breaks the
blocking functionality, so a further workaround was used to block
during the lifetime of the frame by tracking the life of a temporary
file which our internal emacs elisp package created and deleted
specifically during ediff sessions.

This seems like it might be tricky to solve properly. My guess from
looking at the emacsclient source is that a new option would be
required in order to maintain backwards compatibility, maybe something
like `--smart-create-frame` or `-C`, which would behave as in the
expected behavior of the bug report. I think the emacs server might
need some tweaking as well, since I'm not sure there's any existing
combination of options that can be passed through the pipe for this.

On Mon, Nov 2, 2020 at 2:37 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> > To reproduce:
> > 1. Run `emacs --daemon' on a system with a graphical display.
> > 2. Login to the system using a terminal with no graphical display. You
> >    could do this by switching to another virtual terminal (Ctrl-Alt-F1
> >    works on Ubuntu), or SSH in from another machine.
> > 3. Run `emacsclient -c' or `emacsclient -t' in the terminal to connect
> >    to the running Emacs instance.
> > 4. Inside Emacs, run M-x shell.
> > 5. In the M-x shell buffer, run `emacsclient -c'.
> >
> > Ideal behavior: emacsclient creates a frame on the current terminal.
> > Actual behavior: emacsclient creates a graphical frame in the
> >   environment in which it was launched, which is inaccessible from the
> >   terminal.
>
> Indeed the current behavior is a bummer.
>
> The second emacsclient runs within a shell process which itself is
> associated to the *shell* buffer, which can be displayed in several
> windows, including some of them in the GUI.
>
> So in the above case you actually would like to open the emacsclient
> wherever `selected-frame` is (because it's generally impossible to walk
> out way back from the second emacsclient process to the parent tty in
> which the first emacsclient has opened a frame).
>
> Have you tried using `emacsclient` without the `-c` option (you'll have
> to provide a file-name in that case)?
>
>
>         Stefan
>

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eliza Velasquez <exv <at> google.com>
Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>
Subject: Re: bug#25547: 25.1.91; emacsclient -c creates frames on the wrong
 display
Date: Mon, 02 Nov 2020 19:56:24 -0500

> This seems like it might be tricky to solve properly. My guess from
> looking at the emacsclient source is that a new option would be
> required in order to maintain backwards compatibility, maybe something
> like `--smart-create-frame` or `-C`, which would behave as in the
> expected behavior of the bug report.

Maybe we don't need a special option: we should be able to detect this
situation when `-c` is passed from an emacsclient running in a "dumb
tty".

IOW it might be a simple matter of tweaking server.el for the case where
`tty-type` is `dumb` and the `selected-frame` is a non-GUI frame, in
which case we'll just want to create a new tty frame in the same
terminal as that of the `selected-frame`.


        Stefan

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

From: Eliza Velasquez <exv <at> google.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>
Subject: Re: bug#25547: 25.1.91;
 emacsclient -c creates frames on the wrong display
Date: Tue, 3 Nov 2020 10:36:47 -0800

Okay, I'll try to work on this today and see if I can get anywhere with it.

On Mon, Nov 2, 2020 at 4:56 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> > This seems like it might be tricky to solve properly. My guess from
> > looking at the emacsclient source is that a new option would be
> > required in order to maintain backwards compatibility, maybe something
> > like `--smart-create-frame` or `-C`, which would behave as in the
> > expected behavior of the bug report.
>
> Maybe we don't need a special option: we should be able to detect this
> situation when `-c` is passed from an emacsclient running in a "dumb
> tty".
>
> IOW it might be a simple matter of tweaking server.el for the case where
> `tty-type` is `dumb` and the `selected-frame` is a non-GUI frame, in
> which case we'll just want to create a new tty frame in the same
> terminal as that of the `selected-frame`.
>
>
>         Stefan
>

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

From: Eliza Velasquez <exv <at> google.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>
Subject: Re: bug#25547: 25.1.91;
 emacsclient -c creates frames on the wrong display
Date: Wed, 4 Nov 2020 18:00:14 -0800

It looks like I was able to make progress today. Just by modifying
server.el, I've gotten `emacsclient -ce "..."` to create a new frame
based on the currently selected frame's terminal when called in a dumb
terminal. Unfortunately, the command for calling ediff is still very
unpleasant:

emacsclient -ucF "((delete-frame-on-ediff-quit . t))" \
  -e "(ediff-merge-with-ancestor \"${local}\" \"${other}\" \"${base}\"
nil \"${output}\")" \
  -e "(add-hook 'ediff-quit-hook (lambda () (when (frame-parameter nil
'delete-frame-on-ediff-quit) (delete-frame))))"

So perhaps introducing a wrapper script for ediff merges would still be useful.

It's getting late today, so tomorrow morning I'll look into how to
actually submit this as a patch.

On Tue, Nov 3, 2020 at 10:36 AM Eliza Velasquez <exv <at> google.com> wrote:
>
> Okay, I'll try to work on this today and see if I can get anywhere with it.
>
> On Mon, Nov 2, 2020 at 4:56 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> >
> > > This seems like it might be tricky to solve properly. My guess from
> > > looking at the emacsclient source is that a new option would be
> > > required in order to maintain backwards compatibility, maybe something
> > > like `--smart-create-frame` or `-C`, which would behave as in the
> > > expected behavior of the bug report.
> >
> > Maybe we don't need a special option: we should be able to detect this
> > situation when `-c` is passed from an emacsclient running in a "dumb
> > tty".
> >
> > IOW it might be a simple matter of tweaking server.el for the case where
> > `tty-type` is `dumb` and the `selected-frame` is a non-GUI frame, in
> > which case we'll just want to create a new tty frame in the same
> > terminal as that of the `selected-frame`.
> >
> >
> >         Stefan
> >

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eliza Velasquez <exv <at> google.com>
Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>
Subject: Re: bug#25547: 25.1.91; emacsclient -c creates frames on the wrong
 display
Date: Wed, 04 Nov 2020 23:44:01 -0500

> It looks like I was able to make progress today. Just by modifying
> server.el, I've gotten `emacsclient -ce "..."` to create a new frame
> based on the currently selected frame's terminal when called in a dumb
> terminal.

Great!

> Unfortunately, the command for calling ediff is still very
> unpleasant:
>
> emacsclient -ucF "((delete-frame-on-ediff-quit . t))" \
>   -e "(ediff-merge-with-ancestor \"${local}\" \"${other}\" \"${base}\"
> nil \"${output}\")" \
>   -e "(add-hook 'ediff-quit-hook (lambda () (when (frame-parameter nil
> 'delete-frame-on-ediff-quit) (delete-frame))))"

I think the problem is that emacsclient lacks the equivalent of `-f`,
i.e. calling a particular ELisp function where the remaining arguments
can be consumed by that function.  That would solve the problem of
quoting (your above script will stumble when encountering
a file name with quotes in it or with a final backslash).

> So perhaps introducing a wrapper script for ediff merges would still be useful.

We should be able to add a convenience `batch-ediff-merge-with-ancestor`.
Bonus points if you manage to make it work with `emacs --batch -f` as
well as with `emacsclient --<newflag>`.


        Stefan

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

From: Eliza Velasquez <exv <at> google.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>
Subject: Re: bug#25547: 25.1.91;
 emacsclient -c creates frames on the wrong display
Date: Thu, 5 Nov 2020 15:41:08 -0800

[Message part 1 (text/plain, inline)]

Oops, forgot to reply all on my last message. Attached is the patch.

On Wed, Nov 4, 2020 at 8:44 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> > It looks like I was able to make progress today. Just by modifying
> > server.el, I've gotten `emacsclient -ce "..."` to create a new frame
> > based on the currently selected frame's terminal when called in a dumb
> > terminal.
>
> Great!
>
> > Unfortunately, the command for calling ediff is still very
> > unpleasant:
> >
> > emacsclient -ucF "((delete-frame-on-ediff-quit . t))" \
> >   -e "(ediff-merge-with-ancestor \"${local}\" \"${other}\" \"${base}\"
> > nil \"${output}\")" \
> >   -e "(add-hook 'ediff-quit-hook (lambda () (when (frame-parameter nil
> > 'delete-frame-on-ediff-quit) (delete-frame))))"
>
> I think the problem is that emacsclient lacks the equivalent of `-f`,
> i.e. calling a particular ELisp function where the remaining arguments
> can be consumed by that function.  That would solve the problem of
> quoting (your above script will stumble when encountering
> a file name with quotes in it or with a final backslash).
>
> > So perhaps introducing a wrapper script for ediff merges would still be useful.
>
> We should be able to add a convenience `batch-ediff-merge-with-ancestor`.
> Bonus points if you manage to make it work with `emacs --batch -f` as
> well as with `emacsclient --<newflag>`.
>
>
>         Stefan
>

[25547.patch (application/octet-stream, attachment)]

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

From: Eliza Velasquez <exv <at> google.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>
Subject: Re: bug#25547: 25.1.91;
 emacsclient -c creates frames on the wrong display
Date: Thu, 5 Nov 2020 16:55:56 -0800

Actually, I'm realizing now that my patch requires some more work
after testing Emacs in daemon mode without an X server. I'll continue
this tomorrow.

On Thu, Nov 5, 2020 at 3:41 PM Eliza Velasquez <exv <at> google.com> wrote:
>
> Oops, forgot to reply all on my last message. Attached is the patch.
>
> On Wed, Nov 4, 2020 at 8:44 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> >
> > > It looks like I was able to make progress today. Just by modifying
> > > server.el, I've gotten `emacsclient -ce "..."` to create a new frame
> > > based on the currently selected frame's terminal when called in a dumb
> > > terminal.
> >
> > Great!
> >
> > > Unfortunately, the command for calling ediff is still very
> > > unpleasant:
> > >
> > > emacsclient -ucF "((delete-frame-on-ediff-quit . t))" \
> > >   -e "(ediff-merge-with-ancestor \"${local}\" \"${other}\" \"${base}\"
> > > nil \"${output}\")" \
> > >   -e "(add-hook 'ediff-quit-hook (lambda () (when (frame-parameter nil
> > > 'delete-frame-on-ediff-quit) (delete-frame))))"
> >
> > I think the problem is that emacsclient lacks the equivalent of `-f`,
> > i.e. calling a particular ELisp function where the remaining arguments
> > can be consumed by that function.  That would solve the problem of
> > quoting (your above script will stumble when encountering
> > a file name with quotes in it or with a final backslash).
> >
> > > So perhaps introducing a wrapper script for ediff merges would still be useful.
> >
> > We should be able to add a convenience `batch-ediff-merge-with-ancestor`.
> > Bonus points if you manage to make it work with `emacs --batch -f` as
> > well as with `emacsclient --<newflag>`.
> >
> >
> >         Stefan
> >

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eliza Velasquez <exv <at> google.com>
Cc: 25547 <at> debbugs.gnu.org, alexhutcheson <at> google.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#25547: 25.1.91;
 emacsclient -c creates frames on the wrong display
Date: Fri, 06 Nov 2020 07:39:34 +0200

> Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>
> Date: Thu, 5 Nov 2020 15:41:08 -0800
> From: Eliza Velasquez via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> +(defun server-create-frame (nowait proc &optional parameters)

This function's name is too general, and therefore will confuse
someone who tries to learn how server.el works.  Please name it
according to the convention used by 2 other functions in server.el
that create GUI and TTY frames.

Btw, why can't you use server-create-tty-frame here?  IOW, I don't
think I understand this comment:

> +                   ((equal tty-type "dumb")
> +                    ;; Dumb terminals should create frames without
> +                    ;; preference for tty or window system (bug#25547)
> +                    (server-create-frame nowait proc frame-parameters))

Thanks.

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

From: Eliza Velasquez <exv <at> google.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#25547: 25.1.91;
 emacsclient -c creates frames on the wrong display
Date: Fri, 6 Nov 2020 11:14:42 -0800

To answer your second question first, if we try to use
server-create-tty-frame, Emacs will try to run display the frame in
the terminal of the calling client, which it can't do in the case of a
dumb terminal. The next best thing would be to allocate a new frame on
an existing frame's terminal, whether that is on the tty or window
system. Currently a dumb terminal running `emacsclient -c` can only
create new frames on the window system, and this patch should allow it
to create new frames on an existing tty terminal as well (once it's
working correctly). As the initial report suggests, most of the time a
dumb terminal is running `emacsclient -c`, its because it was called
as part of a script in an Emacs subprocess.

Also, I'll rename the function to something like
(server-create-frame-on-selected-terminal) since I agree its purpose
is not clear from the name.

On Thu, Nov 5, 2020 at 9:39 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>
> > Date: Thu, 5 Nov 2020 15:41:08 -0800
> > From: Eliza Velasquez via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >
> > +(defun server-create-frame (nowait proc &optional parameters)
>
> This function's name is too general, and therefore will confuse
> someone who tries to learn how server.el works.  Please name it
> according to the convention used by 2 other functions in server.el
> that create GUI and TTY frames.
>
> Btw, why can't you use server-create-tty-frame here?  IOW, I don't
> think I understand this comment:
>
> > +                   ((equal tty-type "dumb")
> > +                    ;; Dumb terminals should create frames without
> > +                    ;; preference for tty or window system (bug#25547)
> > +                    (server-create-frame nowait proc frame-parameters))
>
> Thanks.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eliza Velasquez <exv <at> google.com>
Cc: 25547 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Alex Hutcheson <alexhutcheson <at> google.com>
Subject: Re: bug#25547: 25.1.91; emacsclient -c creates frames on the wrong
 display
Date: Fri, 06 Nov 2020 17:07:29 -0500

> To answer your second question first, if we try to use
> server-create-tty-frame, Emacs will try to run display the frame in
> the terminal of the calling client, which it can't do in the case of a
> dumb terminal.

The comment could say something like "`emacsclient` is running
inside something like a `M-x shell` buffer: we can't run Emacs in such
ttys, so we use whichever terminal is currently selected".


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eliza Velasquez <exv <at> google.com>
Cc: 25547 <at> debbugs.gnu.org, alexhutcheson <at> google.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#25547: 25.1.91;
 emacsclient -c creates frames on the wrong display
Date: Sat, 07 Nov 2020 10:04:09 +0200

> From: Eliza Velasquez <exv <at> google.com>
> Date: Fri, 6 Nov 2020 11:14:42 -0800
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 25547 <at> debbugs.gnu.org, 
> 	Alex Hutcheson <alexhutcheson <at> google.com>
> 
> To answer your second question first, if we try to use
> server-create-tty-frame, Emacs will try to run display the frame in
> the terminal of the calling client, which it can't do in the case of a
> dumb terminal. The next best thing would be to allocate a new frame on
> an existing frame's terminal, whether that is on the tty or window
> system. Currently a dumb terminal running `emacsclient -c` can only
> create new frames on the window system, and this patch should allow it
> to create new frames on an existing tty terminal as well (once it's
> working correctly). As the initial report suggests, most of the time a
> dumb terminal is running `emacsclient -c`, its because it was called
> as part of a script in an Emacs subprocess.

Thanks for the explanation.

> Also, I'll rename the function to something like
> (server-create-frame-on-selected-terminal) since I agree its purpose
> is not clear from the name.

How about server-create-dumb-terminal-frame instead, since that's
what it really is?

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

From: Eliza Velasquez <exv <at> google.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 25547 <at> debbugs.gnu.org, Alex Hutcheson <alexhutcheson <at> google.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#25547: 25.1.91;
 emacsclient -c creates frames on the wrong display
Date: Mon, 9 Nov 2020 16:14:24 -0800

[Message part 1 (text/plain, inline)]

> The comment could say something like "`emacsclient` is running
> inside something like a `M-x shell` buffer: we can't run Emacs in such
> ttys, so we use whichever terminal is currently selected".

Done.

> How about server-create-dumb-terminal-frame instead, since that's
> what it really is?

Done.

Also, it turns out my code did actually work properly, I think I
accidentally had Emacs running as a daemon last time I tested and
didn't realize. I just tested it with Emacs running on the GUI,
running on the tty, and running as a daemon/emacsclient tty frame. For
each case, I opened an M-x shell, and ran `emacsclient -c`, and each
time it opened in the expected place.

I attached the patch with the new name/comments.


On Sat, Nov 7, 2020 at 12:04 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Eliza Velasquez <exv <at> google.com>
> > Date: Fri, 6 Nov 2020 11:14:42 -0800
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 25547 <at> debbugs.gnu.org,
> >       Alex Hutcheson <alexhutcheson <at> google.com>
> >
> > To answer your second question first, if we try to use
> > server-create-tty-frame, Emacs will try to run display the frame in
> > the terminal of the calling client, which it can't do in the case of a
> > dumb terminal. The next best thing would be to allocate a new frame on
> > an existing frame's terminal, whether that is on the tty or window
> > system. Currently a dumb terminal running `emacsclient -c` can only
> > create new frames on the window system, and this patch should allow it
> > to create new frames on an existing tty terminal as well (once it's
> > working correctly). As the initial report suggests, most of the time a
> > dumb terminal is running `emacsclient -c`, its because it was called
> > as part of a script in an Emacs subprocess.
>
> Thanks for the explanation.
>
> > Also, I'll rename the function to something like
> > (server-create-frame-on-selected-terminal) since I agree its purpose
> > is not clear from the name.
>
> How about server-create-dumb-terminal-frame instead, since that's
> what it really is?

[25547.patch (application/octet-stream, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eliza Velasquez <exv <at> google.com>
Cc: 25547 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Alex Hutcheson <alexhutcheson <at> google.com>
Subject: Re: bug#25547: 25.1.91; emacsclient -c creates frames on the wrong
 display
Date: Tue, 10 Nov 2020 22:14:23 -0500

> I attached the patch with the new name/comments.

Thanks, pushed,


        Stefan

Previous Next

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