> Great news for beginners of Emacs who mistakenly use Emacs in a terminal instead of in a window manager.
I use emacs on purpose in the terminal. Is he being sarcastic here?
I use emacs on purpose in the terminal. Is he being sarcastic here?
But who knows...
But even for more experienced emacs users I'd argue that the terminal version probably is a mistake. Think of it as akin to eating out-of-date food: even if the only other option is starvation, it still probably won't taste very nice, and it could even make you ill.
About all you can say about terminal emacs it is that (unlike vim) it does at least use the familiar emacs keys... provided you can remember that the meta key probably doesn't work. Along with some (random) set of key chords that involve shift. Sometimes by playing with your terminal program's options you can change which half of the keyboard shortcuts are broken.
Still, I'm sure some people like it, and they shouldn't listen to me. It takes all sorts.
I will have to write an article explaining why I feel using Emacs to handle all that is "the more Emacsy way."
The only other problem I had in terminal was getting combinations involving arrow keys to come across properly, but even that was a relatively easy fix.
(menu-bar-mode 0)
(tool-bar-mode 0)
(scroll-bar-mode 0) ; also possibly annoyingDepends 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...
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?
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?