Every vim/tmux user has created an ad hoc, informally-specified, bug-ridden, admittedly probably quite fast implementation of half of Emacs.
replies(4):
Emacs has TRAMP mode - stands for “Transparent Remote (file) Access, Multiple Protocol", it lets you:
- Edit files as if they were local: /ssh:user@host:/path/to/file
- Chain connections: /ssh:jumphost|ssh:target:/file for bastion hosts
- Access Docker containers: /docker:container:/etc/config
- Edit Kubernetes pods: /kubectl:pod:/app/settings
- Sudo seamlessly: /sudo::/etc/hosts or /ssh:host|sudo::/etc/config
- And even combine them: /ssh:server|docker:container|sudo::/etc/nginx/nginx.conf
What you get? Transparent integration - Dired, Magit, etc, they just work. There's no context switching - you stay in your configured Emacs environment. Your keybindings, packages, customizations remain the same. It's multiprotocol: Supports SSH, FTP, SMB, ADB (Android), and more.
Maybe you have no idea how much Elisp code is out there in the wild. There is a LOT of things written in Emacs Lisp. Elisp is probably the most widely used Lisp, with the global total codebase amount exceeding both Clojure and Common Lisp combined.
There are things built into Emacs that some specialized apps don't even have. Did you know that Emacs has built-in lunar and solar calendars, for example?
Just by comparing the sheer amount of code, of course vim+tmux may feel less complicated - they give you fewer opportunities to encounter complexity because they offer significantly less functionality out of the box.
___
That said, there is something nice about composing simple programs and keeping things small. With vim + tmux, I have terminal multiplexing and text editing done and haven't touched that configuration in at least 5 years for vim, over 12 for tmux. I know they offer 'less functionality' out of the box, but after years of tweaking and tons of installed packages I was never able to get that same functionality in Emacs, try as I might.
The main pain points were: - Not having tmux's <c-b z> functionality. You can kinda-sorta-almost jerryrig it with some custom bindings and winner-undo, but you'll still have weird edge cases to think about because you're technically doing a weird undo-tree thing, and all the context (projects, windows, buffers, etc) that emacs maintains will have something to say about that. - ACTUAL vim emulation. Evil mode is really not good enough, and I never had a package that was so hard to integrate without bugs, and when it breaks you have to usually peel back a massive layer cake of competing configurations to try to make it work. Even then, evil-magit has tons of issues, the dot operator doesn't work correctly, and none of the ctrl-i/ctrl-o plugins work across enough contexts to make it make sense like it does in vim. That's a killer feature for me - Embedded terminals that feel anything like tmux in wezterm. In the emacs terminals, there was always so much shit going on navigating in them (and again the layer of evil there) that it felt like walking on egshells using them, they tended to have performance issues and usually couldn't run TUI programs properly. I ended up having a separate drop-down terminal I used in tandem with emacs - Process management. It was always a huge headache for me keeping track of the processes Emacs was spinning up / down through its various plugins and debugging them.
I'd say most tmux+vim setups have something more like 0.00001% of emacs implemented, but sometimes that's a good thing. And again, I love and use both setups for various things.
What the heck are you even talking about? (delete-other-windows) command existed since at least Emacs 18 (released in 1987).
Okay, yeah, I get it, you're complaining that Emacs sorta lacks a dedicated "zoom toggle" that cleanly saves your exact window layout, maximizes one window, then perfectly restores the layout when toggled again. I personally never had any problem with my (toggle-maximize-buffer) command that builds on top of (delete-other-windows)
But do you even realize that you're comparing a bicycle to a Bugatti Veyron - tmux is a simple pane grid with position/size and Emacs windows carry much more state. There are buffer associations, point positions in each buffer, window-local vars, display parameters - margins, fringes, etc., there could be integrations with modes that manage window layouts, there are multiple abstraction layers - framers, pos-frames, buffer display rules.
tmux can get away with a simple layout save/restore because panes are just rectangular terminal regions.
> Evil mode is really not good enough
Ha, I'm a die-hard vimmer, and I laugh at this sentiment. You, my good Sir/Madam/etc., respectfully, have no idea what you're talking about. Evil-mode is the only ACTUAL vim emulation outside of vim/neovim. There's no such thing as a "vim emulation". And I've tried them all - different ones - IdeaVim for IntelliJ, Sublime Vim plugins, VSCode extensions, etc. All of them are pretty much filled with laughable deficiencies; they are not even shadows of the actual Neovim experience. With one notable exception, and that is the vim-implementation in Emacs. In Emacs, Evil-mode doesn't even feel like an extension, an afterthought; it feels like it's a baked-in, major feature of the editor. More than that, it can do certain things even better than you can do it in Neovim.
Anyway, it seems you're complaining for just the sake of complaining, without any evidentiary input. Like I said before, it's of course absolutely obvious that things of lesser capacity will have smaller surface area and thus would feel more stable.
What would be your reaction if I say - my bicycle of 15 years has never needed an oil change or brake fluid drainage. My new car in comparison, is so much more complicated and requires constant attention? You'd probably laugh and call me names. I hope you'd realize how vain this kind of argumentation is - comparing things of completely different caliber.
> Anyway, it seems you're complaining for just the sake of complaining, without any evidentiary input.
I have given multiple specific examples of every claim that I made. HN's formatting did make my comment difficult to read, but the content is there.
> But do you even realize that you're comparing a bicycle to a Bugatti Veyron - tmux is a simple pane grid with position/size and Emacs windows carry much more state.
Yes, yes, this is exactly what I'm saying. It's cumbersome and much more difficult to maintain. There are reasons to like both things (and I have repeatedly made efforts to re-iterate that I do like both options and use both for different purposes).
Your screed about how great evil-mode is does not address any of the specific issues that I have and was never able to resolve wrt using evil-mode in emacs.
> What would be your reaction if I say - my bicycle of 15 years has never needed an oil change or brake fluid drainage. My new car in comparison, is so much more complicated and requires constant attention? You'd probably laugh and call me names.
Incidentally I wouldn't, especially if your bicycle worked for your lifestyle and the constant attention and expense of motor vehicles factored into your decision making process. That's neither here nor there, though, because I happen to own both a bicycle and a car, and I never made the argument you seem to be fixated on. Like my car and bicycle, I use both a tmux / terminal app based workflow and emacs in different contexts and have swapped back and forth between the two at different points depending on my mood and what I'm doing. Sometimes I even (gasp!) discuss my experiences with the two tools in a comments section.
not really TRAMP's fault, of course...
it also doesn't quite work with macOS remotes usually.
again, not purely TRAMP's fault, but a default config and habits issue with ~/.zshrc vs ~/.zprofile and maybe /etc/sshd/config settings, i think. i hasn't fully figured it out yet.
using this kind of "full-screen terminal screen sharing" approach has a more predictable experience, because of the amount of data transferred is usually 1 screen worth of characters (and colors) max, on most keystrokes.
that's both a pro and a con.
it imposes a fixed, network connection dependent input lag and the output is also often redrawn by retransmitting the same data over and over again...
ansi-term however doesn't work thru TRAMP, out of the box, though there are workarounds, like https://github.com/cuspymd/tramp-term.el (hasn't tried it yet)