> 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 wrote: > > > From: Eliza Velasquez > > Date: Fri, 6 Nov 2020 11:14:42 -0800 > > Cc: Stefan Monnier , 25547@debbugs.gnu.org, > > Alex Hutcheson > > > > 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?