tmux VS i3

tmux is a powerful terminal multiplexer that enhances productivity by allowing session persistence, window and pane management, and customization through key bindings and configuration files. It supports scripting for automation, facilitates collaboration with shared sessions, and integrates well with various shells and tools.

Tmux

Configure the frontend Open up a new terminal. P.S. We can split the terminal session using tmux or run it as a system service, but to keep things fairly simple, we would leave the backend running in one terminal and open another terminal for the frontend.

I have been using tmux for a while now. It was really worth it, especially after I started using neovim. One thing was really missing though compared to my previous setup and that was opening URLs. I always used my mouse to do that, but now I couldn't even do that because I am using the good old xterm as a terminal which doesn't have a built in feature like that.

If the cursor is located on a number, the shortcuts +a and +x increments/decrements that number. Not only do I not have any use for this behaviour, +a is also used to control tmux, which I normally use together with neovim.

I said multiplexer didn't I? tmux to be exact. Another game-changer for me. The beauty of using tmux is that I can create sessions, panes, and windows that can then be moved, split, detached, and everything in between. I also have Neovim shortcuts built in so that I can easily move with hjkl which if you know Neovim, that's life.

> tmux/screen do not break copy-paste

Tmux breaks interacting with the clipboard so much that it has its own dedicated Wiki page dealing with all of the different issues and settings: https://github.com/tmux/tmux/wiki/Clipboard

If so, tmux in control mode [1] plus iTerm2 could be what you're looking for. You would use the -CC flag when starting tmux either locally or on a remote host.

This brings all the niceties of an iTerm shell session, but still allow you to detach from tmux and reattach at a later point whilst still using the native iTerm features. Almost indefinite scrollback, as you mentioned. Also good terminal search facilities, and features to filter text in the session to display only lines that contain a keyword. Instant Replay lets you drag a slider and replay old TUI output that may have been erased from the screen [2]. And the configurable hotkeys are very convenient for pane splitting, which I find to be more convenient than the leader-plus-command of tmux. I find the toolbelt window useful, and sometimes define snippets of long cumbersome commands where it isn't possible or maybe appropriate to define aliases on a remote host. For local tmux sessions, I like some of the features of the iTerm shell extensions, like jumping back to the points of previous commands entered, which helps navigate through large amounts of console output. Or the directory name picker based on frecency, which is useful for adding directory names when composing long commands or to jump to a directory when using Zsh (which lets you omit the 'cd' command).

[1] https://github.com/tmux/tmux/wiki/Control-Mode

[2] https://iterm2.com/features.html

You can follow this guide to install Tmux on your system: Tmux Installation Guide

"Nvim 0.10 can now use the OSC 52 escape sequence to write to (or read from) the system clipboard."

This is a big deal! (it shouldn't be, but it is)

My main complaints about vim/emacs in the past was at the sheer complexity of getting something that should not even be a concern (clipboard integration) working properly, when other text/code editors did not have this problem at all.

Searching online, it seems like tmux has some nice documentation related to OSC 52 usage:

https://github.com/tmux/tmux/wiki/Clipboard

I will be playing around with this for a bit to understand it more. But honestly, this is the sort of thing that should "Just Work TM".

"VTE terminals (GNOME terminal, XFCE terminal, Terminator) do not support the OSC 52 escape sequence."

https://gitlab.gnome.org/GNOME/vte/-/issues/2495

That's a shame, but I'm not against using a different terminal emulator. Up until now I did not really have a good reason to.

I switched to the i3 tiling based window manager. Because it's a whole different environment and thinking, it was very different from what I was used to. The volume buttons were working on my keyboard, but I didn't get any visual feedback. Furthermore, the volume percentage could go down below zero and increase up to more than hundread percent. There were times when I was confused why the keys stopped working, but the actual hidden reason was that the volume's value was somehow -500 percent, so increasing it by 5 percent via my keys would have taken a little time.

While I believe Memory Saver was a great improvement, it only works if the tab is hidden or the window minimized. I recently learned the required state is not triggered if the tab is open but on another virtual desktop. At least this is the case with many of not all Linux window managers. Some of the many discussion threads on the topic:

https://github.com/i3/i3/issues/4353

> This is very true, and unfortunately there are very few people working on linux accessibility (including not me! I am part of the problem!).

Accessibility work itself ironically suffers from an accessibility problem. I brought up i3wm above, the issue for that is pretty illuminating: https://github.com/i3/i3/issues/3393

It's not that the devs are saying "this doesn't matter", the devs behind one of the most popular tiling window managers in the X11 ecosystem are saying, "this does matter, but we don't know how to fix it. We don't know what changes we'd need to make to get Orca working."

It's a really fundamental breakdown that's kind of a tragedy because I honestly believe that if accessibility communities were more heavily baked into testing and development in Linux and if this wasn't treated like two separate worlds, it would be better for everyone -- fixing accessibility concerns very often improves interfaces across the board and makes them more powerful.

But... how do you bridge that gap? I don't really know, I tried looking into Orca to see what would need to happen here and bounced off of it pretty hard, it's not a very approachable tech stack and there aren't tutorials or getting started guides. And on the other side of the issue I can preach about needing accessibility input during interface design, but I'm not in a position to give specific advice because I don't use screenreaders or alternate control schemes and I don't know what the biggest problems are.

The people who need to be involved in that process can't get involved because there's a tech barrier in place even for technically inclined people, and because the underlying software locks them out from the start. i3wm isn't ever going to get someone who's intimately familiar with Orca to jump into the conversation because the people who need to use Orca can't use i3wm. So that leaves the people who can address that tech barrier, but they don't know what to do or how to approach the problem because of the lack of involvement and because the communities are isolated from each other. So it's a chicken-and-egg problem and I don't know how to solve it.

This is partially why i use tools like i3 (/ sway). i like the tool; it works extremely well for me; the design has stayed the same for 20 years; there's no profit motive to come along and fuck everything up. it just works. it is boring in the best way possible.

I use MacBook Pro (Retina, 15-inch, Mid-2014) with Manjaro as OS using i3 as a window manager. It isn't perfect, but I'm thrilled with it. I have been a Mac OS user for the last 15 years and wouldn't change what I have now for a Mac OS because I don't need more than what I'm using for development.

Even though, we have moved the official i3 support channel to GitHub discussions, i3's biggest community is still on reddit and if things continue like that there is going to be a lot of helpful content on an increasingly closed platform.

for example, take i3. https://github.com/i3/i3/issues/4478