101–106 of 106 posts
This is a treasure trove, there are quite a few tools I wasn't aware of that I shall start using consistently now.
I'm a terminal jockey and an i3 junkie, and for a long time vim+extensions+Unix tools were my IDE too... but ultimately there is a difference between a powerful editor used like an IDE, and an actual IDE. there are lots of features which get first class.attention in an IDE, which were just kludgy hacks in my beloved vim... and some that simply weren't possible. For example, VSCode Remote container development. The ID…
I tried VSCode several times, but always came back to vim. I think there is a fundamental difference to a purely terminal based workflow. Learning a new commandline tool has almost always been something that paid back for years: CLI cares much more about backwards compatibility than a GUI because it's used in shell scripts. And that's another advantage: you are only one step away from automating stuff. A homogeneousn…
VSCode is good for working in TypeScript codebases—I couldn't find any way to show helpful and long TS compiler errors in Vim nicely.
However, VSCode’s terminal is semi-broken and sessions do not persist, so for other kinds of work that might involve grepping around, running builds and one-off data migration scripts, etc., Tmux+Vim (with respective shortcuts to unify pane navigation) work perfectly.
Earlier quoted context omitted.
I think tmux is overrated, at least when running locally. Tiling WM gets you the same efficient screen layout and keybind driven navigation, and it'll manage also graphical windows that you'll inevitably end up having (like browser). Also you'll avoid any tmux-in-tmux issues if you do connect to remote hosts, and all the terminal features (copypaste, urlgrab, scrolling, search etc) actually will work properly.
> I think tmux is overrated, at least when running locally. Tiling WM gets you the same efficient screen layout and keybind driven navigation Funnily, I have made the opposite path, moving from a tiling WM to tmux into a simple xterm. Tiling wm are overrated, since tmux gives you the same functionality, and you can detach your session easily. What I'm sorely missing is a way to "freeze" all my tmux processes so that…
Unless you're browsing HN on Lynx I suspect you'll have at least a graphical browser running, which means you still need some way to manage graphical windows, because that is simply something that tmux does not do.
Also proper WM is unsurprisingly more capable/flexible for window management because it's not limited by a fixed character cell grid and other idiosyncrasies of terminals
Earlier quoted context omitted.
> I think tmux is overrated, at least when running locally. Tiling WM gets you the same efficient screen layout and keybind driven navigation Funnily, I have made the opposite path, moving from a tiling WM to tmux into a simple xterm. Tiling wm are overrated, since tmux gives you the same functionality, and you can detach your session easily. What I'm sorely missing is a way to "freeze" all my tmux processes so that…
> since tmux gives you the same functionality Unless you're browsing HN on Lynx I suspect you'll have at least a graphical browser running, which means you still need some way to manage graphical windows, because that is simply something that tmux does not do. Also proper WM is unsurprisingly more capable/flexible for window management because it's not limited by a fixed character cell grid and other idiosyncrasies o…
I actually use elinks to read HN and many sites, but I also use regularly a web browser.
However, I try to keep web-browsing usage as sparse as possible. I launch firefox from the terminal, browse tho wherever I need, and then close the browser window. I abhor to have a browser "always open".
Earlier quoted context omitted.
tmux offers a level of abstraction that's missing from a tiling WM alone. You can have 1 tmux server running locally with many sessions (let's say 1 session per project). Then each session can have many windows (separate terminals that are full screen). And then each window can have many panes (splitting that window however you see fit). But if you went with a tiling WM alone without tmux, the WM's workspaces become…
> So now you're stuck having to lean on your terminal emulator for tabs and splitting windows If you have tiling wm, why would you want tabs or especially splitting in terminal emulator? > Most terminals are really bad at those tasks Just don't use bad terminal emulators? And good terminal emulators are better at those tasks than tmux
Splitting is useful so you can see more than 1 thing at a time. You know, tiling. :D
This is especially true if you have a high resolution display such as 2560x1440 or 4k. You can fit a ton of info at once across multiple panes.
> Just don't use bad terminal emulators? And good terminal emulators are better at those tasks than tmux
I've tested dozens across multiple operating systems and haven't found one that that has as low input latency as xterm along with having a better implementation of tabs, splits, searching, being able to name windows, zoom toggle into windows, and everything else tmux does. None of them were even in the same ballpark.
How is UNIX an IDE?
"The primary rationale for using an IDE is that it gathers all your tools in the same place, and you can use them in concert with roughly the same user interface paradigm, and without having to exert too much effort to make separate applications cooperate. The reason this becomes especially desirable with GUI applications is because it’s very difficult to make windowed applications speak a common language or work well with each other; aside from cutting and pasting text, they don’t share a common interface.
The interesting thing about this problem for shell users is that well-designed and enduring Unix tools already share a common user interface in streams of text and files as persistent objects, otherwise expressed in the axiom “everything’s a file”.
Pretty much everything in Unix is built around these two concepts, and it’s this common user interface, coupled with a forty-year history of high-powered tools whose users and developers have especially prized interoperability, that goes a long way to making Unix as powerful as a full-blown IDE."