It's not so much the menubar--I've disabled that--but that I spend most of my time in ssh sessions, and I tend to re-launch emacs all of the time, to the extent that the start-up time of the GUI version bothers me.
So launch it in tmux, and reconnect the next time you jump to that server. If you want faster start time you can also start emacs, run start-server, and then use emacsclient everywhere else to quickly open files from the commandline. In general though, opening and closing emacs all time is the wrong workflow to use with emacs.
> In general though, opening and closing emacs all time is the wrong workflow to use with emacs.
Depends what you are doing. When I'm remote I almost always have an "emacs --daemon" running. Remote admining a custom server ends up with me editing random .conf files in multiple tmux windows. Emacsclient is heaven sent in that case—it pops up faster than vim, with all context already there.
For coding, I tend to run a GUI locally and just have a bunch of buffers open. I still do server-start/emacsclient so the occasional random git command that spawns an editor just pops open a new frame instead of launching a whole new Emacs process...
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?
