Hacker News new | past | comments | ask | show | jobs | submit login

I’ve always found the experience of using shell within Emacs to be poor. I spawn a lot of shell tabs in my workflow as well. If I want anything to do responsive compilation or testing, I’ll just have a separate tab open running some conttest command.

I also find when I use tmux, I avoid splitting windows or panes. It’s always just one singular, dumb window per each shell tab, and just multiple sessions. I’ve tried and tried with it and the overhead of manipulating window placement is just worse than flipping between shells and treat it like all possible windows are always equal to the full shell window.




I use tmux the exact same way. Partially this is because opening multiple terminals is trivial, and it allows all the normal sizing functions that window managers have figured out over years (or that I specifically coded as shortcuts into FVWM2).

Why would I want to use a shitty pseudo-window system inside of a real window manager, when I can just use multiple terminals and connect to a tmux session in each?

Given that I also do a lot of my development remotely, so it doesn't really matter what computer I'm on as long as it has either PuTTY or OpenSSH on it, and all it really takes is the remote system being set up initially with vim (which generally exists on the remote system already), optionally with a single .vimrc copied over, or for a more heavy environment a .vim directory with a few pathogen plugins.

It is a trade-off. There are some things that are somewhat harder to do in a text environment (although it's generally just "harder", not nearly impossible), but there's also quite a bit of versatility. I have quite comfortably worked from a netbook for a month before. Smaller screen size and keyboard was the only problem.


> Why would I want to use a shitty pseudo-window system inside of a real window manager, when I can just use multiple terminals and connect to a tmux session in each?

With my workflow, Emacs is the window manager. It's good at that, especially in text mode.

While terminal emulation / alternatives in Emacs have some rough corners, your all shell interactions are within Emacs buffers, which give powerful workflow advantages if you want to refer to previous results, or if you want to do some ad-hoc scripting.


> Emacs is the window manager.

Yeah, I've tried that with vim windows. It wasn't to my liking.

> your all shell interactions are within Emacs buffers, which give powerful workflow advantages if you want to refer to previous results, or if you want to do some ad-hoc scripting.

I'm not sure I'm understanding the advantage you see. I use named tmux sessions that survive beyond terminal closing that I reconnect to. I have history for months in those. I can use two of those and have an editing window and a window to see compile/test results. If it's a remote connection and the network fails, I just reconnect and reattach the tmux session, and I'm in the same position I was, with the exact same screen shown and history. I can move from home to work with the same amount of easy as well.

Since I would run tmux anyways just for that capability, I'm not sure the benefit I get out of folding both those windows into the editor, other than harder to manage resizing, and harder to manager if I want to add or remove windows temporarily.

I'm not sure what making the buffer part of the editor is gaining there specifically, but I think there is something that I'm not gleaning from how you're explaining it. I'm just not sure it's enough to counteract the pain of in-editor window management (for me).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: