Note however you can't use emacs-server/emacsclient with the GUI over a SSH connection and tmux. With remote sessions and emacs you really have to choose between long start-up times and terminal-only editing.
Are you sure you can't? Pretty sure I have used a remotely started emacs --daemon and used emacsclient -c with DISPLAY set correctly and X forwarding to bring a GUI frame locally, and then use emacsclient on that machine to pop open files from the remote command line to the existing, local gui frame. If you lose your connection the gui client might kill your daemon (at least with gtk) though.
Or do your editing from ansi-term or eshell from within the long startup gui you have running on the remote system. Eshell find-file will pop to that buffer from the commandline.
It is unfortunate that tramp often feels too slow for these tasks, as that would seem like another logical approach. Maybe it's faster without ido and friends doing lots of completion requests?
I'm probably misunderstanding you, but that is exactly what I'm doing. I have an emacs-server running on a remote server to which I connect via SSH to a tmux session and from there start an emacsclient gui via SSH X forwarding (you might have to set DISPLAY). Works like a charm.
I think parent was saying that you can't run a single daemon on machine emacs-host and launch clients from needs-editing-a-conf-server1...n (possibly with x11 only running on different host workstation1)?
You seem to be running n daemons on needs-editing-a-conf-server1..n and launching n clients on each of these, and "just" transporting the display(s) back to your workstation via x11 forwarding over ssh.
Henche - either run "redundant" daemons or suffer long-ish startup times.
How much resources does your typical long-running daemon consume?
He's using tramp to copy an auth key to the remote system, but then using that to allow the remote emacsclient to talk back to the host. Has some caveats, but it's essentially the single daemon, many remote clients approach?
Or do your editing from ansi-term or eshell from within the long startup gui you have running on the remote system. Eshell find-file will pop to that buffer from the commandline.
It is unfortunate that tramp often feels too slow for these tasks, as that would seem like another logical approach. Maybe it's faster without ido and friends doing lots of completion requests?