Hacker News Reader

Comment by aumerle | Hacker News Reader

For me (I am the author of kitty) it is for two reasons:

1) Multiplexers are a hack -- there are various problems with them, such as passing control codes through safely, keyboard shortcuts, performance, etc

2) Tiling WMs -- these can work (in fact I use a tiling WM myself) however, the nice thing about having tiling (and tab management) built into the terminal is that you can manage terminal windows and other windows differently on the same screen. For example, on small screens I like to have most GUI windows such s browser, etc. maximized, but I like to have terminal windows side-by-side, this is hard to manage if you want to have them on the same screen. With tiling built into the terminal, managing terminal windows is in a separate "namespace" from all other types of windows

View on HN

Multiplexers may have some control key quirks but they seem to be essential for any workflow that involves a remote machine or VM. I can have the same workflow everywhere with tmux, local and remote. Though nesting tmux sessions is annoying and can be more convenient to have a remote session in its own terminal window.

Why? The only advantage I can see to running a multiplexer under ssh is that you can resume after disconnection. There are plenty of non-multiplexer based solutions for that. And you can have the same session locally or remotely if you terminal emulator locally, as long as the terminal emulator support sessions, which kitty does.

You opinion tiling WMs makes me thing you haven't tried something dead-simple like i3wm. What you describe is a non-issue for us i3 users.

Really? Tell me how you would do the following with i3 or whatever tiling WM floats your boat. Have four terminal windows arranged in a grid, run a random gui program by typing the name of the program in one of those terminals and have the program open maximized. Close the program by using a quit command inside the program and have the terminals laid out in the grid again. And all this without having to use any window management/layout commands, keyboard shortcuts, mouse gestures.

> And all this without having to use any window management/layout commands, keyboard shortcuts, mouse gestures.

I need to interact with my computer for it to do stuff, I think you somehow exagerated here.

Exluding that incoherent requirement, I'd have two choices:

1. Run the command in a terminal and hit super+f 2. Run the command in a terminal, super+right, super+w (I can switch back and for to <-> from the terminal).

Bonus point of using i3 is that I can optionally have any external program become part of my grid or add/remove exiting terminals to/from different mixed layouts (or workspaces). With multiplexers you're screwed and can't do that.

Note: I do use tmux on all my sessions, but it's mostly for "tab" support, or attaching/detaching (even from different workstations).

I use awesome, and there's a way you can assign particular programs to specific tags, so that they always open on that tag. I'd be surprised if i3 didn't have a way to do the same, given that even dwm can do it ;)

Then, there's a third option in addition to the two you mentioned: spend two minutes (if that) doing the one-time configuration of having the wm reserve a tag for your browser (and perhaps other GUI apps that you anticipate frequently needing/wanting to run full-screen). In awesome, you'd do that by adding an entry to your global rules table like this one (in rc.lua):

    { rule = {
        instance = "firefox"
      },
      properties = {
        screen = "HDMI1",
        tag = "3"
      }
    }

Which will configure awesome so that any time a new client becomes managed by the wm, it will ensure that its window opens on the XRandR screen "HDMI1", and specifically on that screen's tag "3". ("3" is a string here because, while tags are by default "integers", "1" - "9", they can be named by any string afaik, and many people will rename them things like "www", "irc", "term", etc.).

You can also use awesome-client(1) to send Lua code to a running awesome instance for execution within the wm's context. This could be tossed into a shell script (and parameterized as you see fit) for convenience, if desired:

    $ awesome-client <<EOF
      require("awful").spawn("firefox", {
        screen = mouse.screen,
        tag = "3",
        switchtotag = true
      })
    EOF

The same awful.spawn() call you'd send to awesome-client can also be bound to a keystroke or a menu entry for quick access.

As for me, I tend to only use tmux under X11 if I'm worried about losing an ssh connection and therefore (without tmux, of course) the ssh session. However, I have DEC vt520 glass TTY that connects via RS-232 serial cable to a couple of servers (one OpenBSD, the other FreeBSD) and, while the terminal is pretty damn featureful, it has limited scrollback and awkward copy/paste functionality. So, on that terminal I use tmux quite a bit (although it seems to be rather chatty and during periods of heavy pty traffic can sometimes wind up spitting a garbage glyph on the screen here and there, but I think I may just need to increase the baud rate (despite already being set to ~56 Kbaud! cha-tty!)). The vt520 also only supports 2 sessions at once directly (and I can't even figure out how to get the OS to recognize the second one -_-), so tmux's multiplexing capability is also greatly appreciated when I'm basking in the amber glow.

Reply on news.ycombinator.com