I want to make sure that people understand that you do not have to use a terminal to interact with Emacs: instead, you can use one of Emacs's "graphical" front ends for MacOS, Windows, X.org or Wayland.
Visually, graphical Emacs looks so much like Emacs running in a terminal that if the tool bar has been turned off (and most users decide to turn it off) most non-users of Emacs will assume (incorrectly) that a graphical Emacs window they see running on a colleague's computer is a terminal window (unless perhaps the window is currently displaying an image). (Graphical Emacs is an image viewer among other things.)
In a survey of Emacs users, 80% said that they use one of the graphical front ends.
Counterpoint: If you want a terminal w/o the bloat of a full GUI, but still most of the advantages, `xterm-mouse-mode` will get you 80% of the way there:
(require 'mouse)
(xterm-mouse-mode t)
(mouse-wheel-mode t)
(setq mouse-wheel-scroll-amount '(1 ((shift) . 1))) ;; scroll one line at a time
(setq mouse-wheel-progressive-speed nil) ;; don't accelerate scrolling
(setq mouse-wheel-follow-mouse 't) ;; scroll window under mouse
(setq scroll-step 1) ;; scroll smoothly
Also, I should point out that I use `(setq auto-save-default nil)` - as God intended.
People are going to be using Emacs with a monitor. It's more bloat to have to have a GUI application that emulates a terminal and then run Emacs inside that emulator instead of just having Emacs be the GUI itself.
Unsaid in all of this is that Emacs isn't my main text editor - that is the job of BBEdit where the GUI is both expected and rather good - instead, it is the "editor of last resort" (Vim is inscrutable to me).
The emacs GUI inside a terminal window - invoked w/ xterm-mouse-mode - is still rather minimal. I'm thinking more about emacs-gtk or Aquamacs. You could argue that the GUI gives you access to more system capabilities in a straightforward way - buttons/controls v keybindings - but this isn't a dealbreaker for me.
As long as I have a readily available reference for keybindings, that's good enough for me.
I’m not sure what your point is, exactly. If you run Emacs in a terminal, you can press F10 to access the menus. They’re the exact same menus as you would see in the Emacs GUI.
There’s just no way that the GUI adds bloat in any meaningful sense; it’s the same program either way.
To my way of thinking, the idea that you would remove the toolbar in graphical mode defeats the purpose.
Emacs keybindings are complicated enough that I'd rather keep the ability to click a button available at all times even if I don't use it regularly - see my prior comment re BBEdit.
Such is life that I have some physical issues with my hands that make a purely keyboard driven interface occasionally uncomfortable. The chorded keystrokes in Vim were not satisfying to me, so I went in an emacs direction ¯\_(ツ)_/¯
When I started building out my init.el, it became apparent that I needed an escape hatch from time to time - this is it.
I don't run emacs in a terminal emulator. Emacs is my terminal emulator. All my terminal programs get run in a (graphical) emacs shell-mode buffer. The rare program that needs full screen control uses term-mode.
It's not the most featureful or fastest terminal emulator, but I can jump around the buffer like any other buffer and seamlessly access it along with the other content I'm editing.
On a remote computer where I can't run a graphical emacs, I either remotely edit files via tramp, or run a headless emacs server process and connect remotely with a graphical emacsclient.
I also use emacs graphically, somehow I managed to switch after years of using it in the terminal and now I prefer it. However, I've never managed to settle on any of the terminal emulation modes. Just too many keyboard shortcut conflicts and complicated magic to remember how to copy and paste between different types of buffers.
These days I've pretty much settled on having and emacs window and GNOME Terminal side by side as my two main work windows, and it's pretty comfortable. I like that I can mouse select and copy from the terminal window and then C-y into emacs and vice versa.
If I really have some need I might still open a shell or ansi-term session but it's pretty rare now. Sometimes it's convenient when I find myself in a remote shell session and want to have a text editor and shell vertically tiled, I'll just run emacs with ansiterm because for the life of me I can't ever remember the screen keyboard shortcuts for splitting windows.
It's been a while since I've run with that configuration, but setting the variable server-use-tcp to non-nil enables it. On startup, the server creates a file with the connection details that emacsclient can consume. I think it just works if the filesystem is shared between client and server machines but command line options allows the use of a copy on the client.
Good point. I never considered that people might think I run Emacs in a terminal. Graphical Emacs is a lot better, but it's still great that 90% of stuff works and looks the same in a terminal.
I agree. I use X based emacs and the protocol is efficient. The experience seems as lightweight as using a terminal, and NOT like using VNC or similar.
advantages include fonts (even different ones at the same time), menus, mouse, colors, multiple frames/windows, and more...
You can also run the graphics locally use tramp to access remote systems. I can edit config files on a remote linux-based router which basically has busybox, with all the bells and whistles.
I've always drifted back to the terminal based emacs for two reasons.
While I've been using X11 off and on since the 90s, I still do not understand how to deal with fonts beyond helplessly googling for a constructive command I eventually stumble on something that works and then I have to leave it alone.
The display performance of most terminal programs is still noticeably faster than the X11 setup I end up with in a corporate environment.
The font stuff is 50x better than it used to be and there's even a reasonable font selector built right into the GUI with the "Set Default Font" in the context menu (ctrl-right-click). And then you can "save" that from the GUI and get a line like this in your .emacs:
'(default ((t (:family "FantasqueSansM Nerd Font Mono" :foundry "PfEd" :slant normal :weight regular :height 98 :width normal)))))
Right. There's also the sophomorically named "TRAMP" for connecting from a locally hosted emacs session to files across a wide range of protocols including ssh.
TRAMP also exhibits a wide range of performance problems. Getting it not to hang the display of the buffer list or lock up Emacs completely for minutes at a time requires a deep dive in to a decade of Stack Overflow breadcrumbs. I've done this, and I'm still not completely satisfied with the performance. I do however love the concept.
No, it requires only one thing: turn on persistent SSH connections. This means that new SSH connections to the same server do not actually require opening a new TCP connection, do not require negotiating new session keys, and do not require additional authentication. To turn this on, add these settings to your ~/.ssh/config file:
ControlMaster auto
ControlPersist yes
ControlPath ~/.ssh/control/%C
You should also use key–based authentication so that TRAMP never has to ask for a password, but this is less important once you are using persistent connections. Add something like this to your ssh config:
Host orod-na-thon
Hostname 192.168.2.133
User db48x
IdentityFile ~/.ssh/id_ed25519_your_private_key
Now go to Emacs and open up /ssh:orod-na-thon:~/.ssh/authorized_keys. This is the TRAMP path for your authorized_keys file on the machine named orod-na-thon. It will ask you for your password. Paste in your public key (which you can get by opening up the .pub file that goes alongside the private key in ~/ssh), and save it. Now future connections to orod-na-thon will be able to authenticate automatically using this key pair, and there will be no password prompt when you open a file there.
One problem that I looked briefly into, but have not found a solution is that often I'm browsing the file system (in a terminal) on the remote box and want to open up a file in a certain location (often just for a quick edit). The process of typing pwd, and copying the location into emacs (similar applies to Neovim) already is too much friction, that it's easier to just open the barebones Vim on the remote.
Anyone aware of a solution of how to start the local editor from the remote to open the remote file?
Best solution to that is to use Eshell. Run `M-x eshell` to open the shell inside Emacs (on your local machine), then type `cd /ssh:orod-na-thon:path/to/files`. This will transparently ssh to the server and change to the path to your files. The `ls` command will now show the files that exist on the remote server rather than the local computer. You might now expect that there would be an eshell command that you could type to open a remote file in your local Emacs, but there isn’t.
No, in Emacs you always open a file by typing `C-x C-f`. (Unless you rebound it to some other key, in which case make the obvious substitution.)
Any time you hit `C-x C-f` to open a file it defaults to opening files from the working directory of the current buffer. The working directory of the eshell buffer is on the remote server, so the default list of files that you see are all the ones you were already looking at with `ls`. You can start typing a filename and autocomplete will do the rest.
This is an even deeper and more convenient composition of the shell and the editor than having special commands for tasks like opening a remote file in the local editor.
> You might now expect that there would be an eshell command that you could type to open a remote file in your local Emacs, but there isn’t.
No, in Emacs you always open a file by typing `C-x C-f`
`C-x C-f` calls the `find-file` function which can be called directly from eshell
Technically correct, but it is way easier to hit `C-x C-f` just like you would when you are opening a file at any other time. No need for special cases, you just open the file.
Try some variant of this in your remote .bash_profile or what-not:
if [ "$PS1" ]; then
export PS1='\h:\w\$ '
if [[ "x${TERM}" = "xeterm" || "x${TERM}" = "xeterm-color" ]]; then
function set-eterm-dir {
echo -e "\033AnSiTu" $(whoami)
echo -e "\033AnSiTc" $(pwd)
echo -e "\033AnSiTh" $(hostname -f)
}
PROMPT_COMMAND=set-eterm-dir
fi
fi
Now, locally, invoke M-x ansi-term, then within the ansi-term ssh to the remote machine. Change dirs, hit C-x C-f to open a file in the current (remote) directory.
Apologies, I meant to add more saying I could not get a remote machine to invoke the local emacs reliably. I got close with hacking up emacsclient to ssh back, but was eventually stymied by new network policies at $JOB and eventually settled for the above.
In the specific case of Emacs, assuming you're connected via ssh, sshd is running on port 22 of both hosts, an Emacs server is running locally, and emacsclient is in the default local path, a bash function or script along the lines of
for i in "$@"; do
ssh "${SSH_CONNECTION%% *}" emacsclient --no-wait "/ssh:$(hostname):$(realpath "$i")"
done
should work.
For best results, use ssh-agent + agent forwarding to avoid password prompts.
> The process of typing pwd, and copying the location into emacs (similar applies to Neovim) already is too much friction, that it's easier to just open the barebones Vim on the remote.
Vim has had the ability to open files remotely over ssh, sftp, etc. for a long time using the built-in plugin netwr [1].
Neovim takes it to another level [2]:
Nvim's RPC functionality allows clients to programmatically control Nvim.
Nvim itself takes command-line arguments that cause it to become a client to
another Nvim running as a server. These arguments match those provided by
Vim's clientserver option.
Yes, that's great, and it makes things extremely snappy while the socket connection remains open. Sleep your computer overnight, experience some network stormy weather, leave Emacs buffers open for weeks (as one does) and eventually one of those ControlMaster sockets are going to become wedged, and when that happens you're going to go through some things.
If that happens and you don’t want to suffer through the default 30–second (or whatever it is) timeout, then shorten it. Add `ConnectTimeout 5` to your config.
Good idea fine tuning the timeouts. I took your suggestion and dropped the SSH ConnectTimeout to 5, I was still using the default. I also peeked at the Tramp timeouts, and I realized that I had the variable as tramp-connect-timeout and not tramp-connection-timeout. Thanks!
I had this trouble when I upgraded emacs. I'm now stuck on 27.2 because later versions broke tramp in some way, and I haven't taken the time to debug it.
Visually, graphical Emacs looks so much like Emacs running in a terminal that if the tool bar has been turned off (and most users decide to turn it off) most non-users of Emacs will assume (incorrectly) that a graphical Emacs window they see running on a colleague's computer is a terminal window (unless perhaps the window is currently displaying an image). (Graphical Emacs is an image viewer among other things.)
In a survey of Emacs users, 80% said that they use one of the graphical front ends.