bug#25547: 25.1.91; emacsclient -c creates frames on the wrong display

[Eliza Velasquez]

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@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@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
> >