Hacker News Reader

Comment by tombert | Hacker News Reader

I've gotten made fun of because I've said my "IDE" is `tmux` in the past; my typical development environment is a tmux split, where an editor (usually NeoVim, sometimes Emacs) does editing, and the bottom half is a terminal running either a dev server or just the compiler command.

It's not perfect, but I like how I can basically swap any component out (except tmux itself).

View on HN

That's what I do, too. Vim and a couple shells and I'm happy.

I despise autocomplete and will not use things that force it on me. IntelliJ has options to make it not aggressively, in-your-face annoying, so I can live with it, and do use it for access to some tooling we built at $dayjob.

But after spending a day turning off all the bullshit, installing vim bindings, etc. I get... a slow, memory-pig semi-substitute for my shell environment that still is less flexible.

Progress.

> I despise autocomplete

Could you elaborate on why that is? I feel similiar but I cant just tell why

A lot of autocomplete systems will put text into the document FOR you, like when you press enter or space or something. It is infuriating. Having the suggestions that you can access if you want is usually fine, but sometimes also having that bubble pop up and cover code below or above that you need to see is also infuriating.

Thanks for the answer

I find it extremely distracting. A little hard to describe, but it is sort of like trying to remember one number while someone is babbling other numbers, or trying to keep a train of thought while listening to multiple other conversations.

There's also the visual noise - I hate it for the same reason I hate tool tips and similar. Popping up flyovers on top of whatever I'm trying to focus on is utterly infuriating and I've never understood why people think that's good UI. It is like shoving your hand in my face if I look at you.

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 would stop using tmux entirely and switch to this, but the cluster I work on has 2 factor authentication which is absolutely annoying.

You may wish to investigate the ControlMaster directive in your SSH configuration. Depending on how the two factor authentication system works, you may be able to authenticate just once for many concurrent SSH sessions.

Here's what I use to keep SSH connections open for 4 hours: https://blag.felixhummel.de/apps/ssh.html#config

It took a while to find out that `Host *` should be at the end of the file if you want to override things.

> 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 they can be recovered in the case of a system reboot.

Seems like a great idea. Lack of persistence bugs me about my i3 / tmux / emacs setup.

Google brings [1] but I haven't tried it yet.

1: https://github.com/tmux-plugins/tmux-resurrect

yes, but this is a mock-up of a real freeze. What I want is independent of tmux: a way to freeze a process and all its children and save it into a file. The file is then opened when rebooting, or even on a different computer. There was this:

    https://github.com/maaziz/cryopid

Have you looked at CRIU?

Yes, but does it really work? The documentation is written in the future tense.

It works for most things. You can always try it for your usecase and see how it goes.

Rather than freeze them I have a tmuxinator[0] config per project that opens all of the panes and tools I tend to use. Usually something like: editor, extra (often my rails console or database prompt), git, tests, server, logs.

I know the numbers off by heart so can switch without looking.

[0] https://github.com/tmuxinator/tmuxinator

Tmux Resurrect works pretty well:

https://github.com/tmux-plugins/tmux-resurrect

> 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 of terminals

> Unless you're browsing HN on Lynx

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".

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 sessions and your terminal becomes a window. So now you're stuck having to lean on your terminal emulator for tabs and splitting windows, but you're also on the hook for it having buffer searching, copying URLs, scrolling and other things. Most terminals are really bad at those tasks but tmux is great with them when combined with something like xterm (a low input latency terminal).

Plus with tmux you have the option to easily save and restore everything with tmux-resurrect, and you can take your whole set up and replicate it on Linux, MacOS and even Windows with WSL and it all works the same as long as you find a good light weight terminal on each platform.

I think there's a lot of value in using both a tiling WM and tmux together. tmux basically super charges any terminal into having world class support for everything a terminal needs to do. Even if it didn't persist sessions, it would still be really valuable. IMO it's severely underrated. People's eyes widen and still get impressed when terminal emulators add basic tab support. If they only knew what was lurking around the corner with tmux!

> 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

> If you have tiling wm, why would you want tabs or especially splitting in terminal emulator?

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.

I honestly just use tmux as a tabbed terminal with saveable state. For someone who works remotely from multiple locations, attach/detatch is life changing.

I'm glad I'm not the only one.

I love tmux, but I prefer vscode to vim, and I'd rather just keep tmux as the place where I keep all my terminal panes/windows. A lot of people look at my tmux screen and assume that I'm using vim or emacs.

I've been using this sort of setup for over a decade. I try IDEs from time to time but typically I find it just gets in the way or buries the things I care about among 100 other features I would never use. Additionally, IDEs are often optimized for one platform or language but not others or for general use. With vim I can use one editor to code, write email, write documentation, etc.

With neovim you can have autocompletion, error checking, git integration, project file navigator, and many other IDE like features but without the cruft.

Performance and stability is stellar compared to the IDEs I have experience with (eclipse, visual studio, xcode, and PHP storm). Especially if you use a terminal that uses the GPU to render the screen. With startup times there is no competition, tmux can keep your terminal session alive even after quitting the terminal which means their is essentially zero startup wait.

Lately, I've been playing with the idea of combining tmux, nano or purpose-built kilo editors[0], fff [1] or slmenu [2][3], and kanban.bash [4] into my own little "agile" terminal IDE.

[0] https://github.com/antirez/kilo

[1] https://github.com/dylanaraps/fff

[2] https://www.youtube.com/watch?v=SlJto75auCA

[3] https://github.com/joshaw/slmenu

[4] https://github.com/coderofsalvation/kanban.bash

I tried to get into tmux but it started to get frustering as someone coming from using the native shell. I even fell down the rabbit hole of wonking with my tmux config, trying different versions, etc.

I just could not stand the mouse behavior, ultimately. Switched to screen for some things. Sometimes its just easier to use the trackpad to scroll than page up/down or select text with the cursor vs. with the keyboard. Can't do both in tmux; either you can scroll in programs and not in the shell, or loose 'modern' copy paste and select behavior with the mouse as well as scrolling in programs to get scrolling in the shell. I just couldn't figure out how to have it both ways like the native shell.

You can but you need to change the mouse mode

In newer versions of tmux

   set -g mouse-mode on
   # make scrolling with wheels work
   bind -n WheelUpPane if-shell -F -t = "#{mouse_any_flag}" "send-keys -M" "if -Ft= '#{pane_in_mode}' 'send-keys -M' 'select-pane -t=; copy-mode -e; send-keys -M'"
   bind -n WheelDownPane select-pane -t= \; send-keys -M

I'm getting invalid option: mouse mode in tmux 3.0a, and unknown option: mouse-mode in tmux 1.8.

That's the thing with these .tmux.conf hacks you see floating around github and stack overflow. The tmux devs changed the relevant settings practically every other release and offered no compatibility, so most of what you find just doesn't work with your build.

But even those snippets that do work with my builds, you can't have it all. Either scrolling up takes you past the panes and into the std output of the native shell, or you enable mouse mode and can scroll in your shell but loose the ability to scroll in editors like nano and programs like less.

Maybe if there was a way to automatically turn off mouse mode when running programs and flick it back on when exiting to the command line, but I'm not well versed enough in the .tmux.conf syntax to figure it out without too much trouble.

I created something that enables the scroll based on process name https://github.com/noscript/tmux-mighty-scroll

Ohh...nice. And to GP, if this doesn’t work well for you, try the combination of abduco and dvtm. Before I joined Red Hat, that was my terminal multiplexer combination of choice. However, because they’re in EPEL which most of my customers don’t use, I forced myself to revert to tmux. I remember initially missing abduco + dvtm but get 95% of what I want with tmux. abduco feel slightly better about maintaining session state.

I use nested tmuxes, one per workspace, and one to hold all of them, with small scripts to launch new ones making sure that the top-level tmux window is named the same as the workspace tmux session.

In every C/C++/Java workspace I run cscope on tmux window #0, with a CSCOPE_EDITOR script that launches the real $EDITOR in a new window in the same session, with the window named after the basename of the file being edited.

This makes it trivial for me to find my way around all my shells and running $EDITORs.

Altogether this allows me to avoid using the mouse a great deal.

Compile mode on emacs is pretty sweet. You can bind it to a shell command for a particular major mode and compile from a couple keystrokes. The compile buffer can be interactive (for debugging) which is also pretty sweet ! And Ctrl-g makes the compilation buffer disappear so it's heaven :)

You could throw an extra layer of fun and use a windows manager with multiple workspaces/screens that serves as your IDE. One workspace could be for coding/debugging, another workspace could be for servers/system diagnostics/etc. Another could be for multimedia/distraction/etc.

I actually do something similar to that when doing any kind of GUI apps; usually I have a workspace for my browser, another workspace for VLC, etc.

Reply on news.ycombinator.com