kitty tmux like daemon

[mihaicristiantanase]

I've being using kitty for quite some time and slowly questioning the need of a terminal multiplexor (tmux). One thing that I could not find in kitty, though, is the ability to run it as a daemon (server) just like tmux. So, for example, I can create a kitty session and close the UI without destroying the current session. Which means that, later, I can resume that session.

Do you have any plans on implementing this behavior?

Thanks!

[BourgeoisBear]

@kovidgoyal where do you keep your opinions on these things? I'd love to read them.

My take is that terminals are a horrible hack to begin with, we are already fallen and impure, so why not add drugs to the orgy? But I haven't written a GPU accelerated terminal emulator, so there is much room for enlightenment on my side.

[kovidgoyal]

On Wed, Jun 03, 2020 at 09:33:53AM -0700, Jason Stewart wrote:

@kovidgoyal where do you keep your opinions on these things? I'd love to read them.

I'm too lazy to blog I'm afraid, but searching the kitty issues for multiplexer should find plenty of my comments on them. In summary: multiplexers add unnecessary overhead, suffer from a complexity cascade, because they actually have to translate escape codes, modifying them in hackish ways to get them to work with their concepts of windows/sessions.

Energy/performance wise they are poison, every byte has to be parsed twice, once by the middleman and once by the terminal. And they act as a drag on the ecosystem as a whole, making it very hard to get any new features. Designing features becomes harder because you have to design for compatibility with a horrible hack and the diffusion into the ecosystem tends to get gated by basically a handful of individuals with, let's say, very limited vision.

My take is that terminals are a horrible hack to begin with, we are already fallen and impure, so why not add drugs to the orgy? But I haven't written a GPU accelerated terminal emulator, so there is much room for enlightenment on my side.

Terminals are fine, certainly better than any other interface paradigm I have ever seen :) They are of course sadly neglected and have a lot of legacy baggage it would be good to get rid of cough ncurses cough.

It never ceases to amaze me how little effort we developers put into the tools we use.

[test-account-0]

From my (user) perspective I need terminal only to attach to my tmux. :)

[ctrlcctrlv]

@BourgeoisBear What means NIH? @kovidgoyal Would you consider a tmux fork as an appropriate way to close this issue? Similar to how we currently treat GLFW upstream. Tmux only requires ncurses and libevent to build, we could even stick the fork in the main repository as GLFW

[kovidgoyal]

On Thu, Jun 04, 2020 at 09:48:22AM -0700, Fredrick Brennan wrote:

@kovidgoyal Would you consider a tmux fork as an appropriate way to close this issue? Similar to how we currently treat GLFW upstream. Tmux only requires ncurses and libevent to build, we could even stick the fork in the main repository as GLFW

No, I am not going to host tmux in kitty's repo. You are wleocme to make a fork of tmux separately if you prefer.

This issue will be closed someday when I have a couple of weeks to sit down and implement this. Or when someone else steps up to do it.

[BourgeoisBear]

Answer to @ctrlcctrlv : NIH = Not Invented Here

[zsugabubus]

[Off: @rafaeln, what’s that monitor tool/dashboard in the middle?]

[EvanCarroll]

Six months after @kovidgoyal reinvents tmux, you will all be saying "fuck this antiquated tmux shit". Master plan can't be reduced to writing. Give it time, we'll have terminals remotely connecting to windows desktop sharing, and you'll be playing Overwatch in your terminal split with GPU rendered ligatures.

[rafaeln]

[Off: @rafaeln, what’s that monitor tool/dashboard in the middle?]

It's bashtop

[anicolao]

I wanted to be able to easily start persistent shells on an ssh target named devcon and access them easily. dtach+kitty are sufficient for my purposes, and my hacky script can probably be adapted by people wanting functionality described in this issue.

Please note that remote control is inherently dangerous if you are on a target system where someone other than you has root.

KTERM_DIR=/tmp/$USER/terminals
export PROMPT_COMMAND="kcompletions; $PROMPT_COMMAND"

if ! test -d ${KTERM_DIR}
then
  mkdir -p ${KTERM_DIR}
fi

function kbash {
    T=$(kphrase)
    KTERM_NAME=$T dtach -n ${KTERM_DIR}/$T bash
    echo $T
}

function klist {
    for t in $(find ${KTERM_DIR} -type s)
    do
        echo ${t##*/}
    done
}

function kcompletions {
    complete -W "$(klist)" kattach
    complete -W "$(klist)" kterm
    complete -W "$(klist)" ktermsize
    HN=${KTERM_NAME}
}

function kattach {
    dtach -a ${KTERM_DIR}/$1 -r winch -z
}

function kescape {
    echo -en "\033P@kitty-cmd"
    cat -
    echo -en "\033\\"
}
function ktermsize {
    T=${1-${KTERM_NAME}}
    if test -f ${KTERM_DIR}/size*${T}
    then
        cat ${KTERM_DIR}/size*${T}
    else 
        echo "-o initial_window_height=30c -o initial_window_width=80c"
    fi
}

function kterm {
    TERMINAL=${1-$(kbash)}
    cat - <<SEND | kescape
{"cmd":"new-window","version":[0,18,2],"no_response":true,"payload":{"window_type":"os","args":["$(echo "/usr/local/bin/kitty -1 $(ktermsize $TERMINAL) ssh -A -t devcon dtach -a ${KTERM_DIR}/$TERMINAL -r winch -z" | sed -re 's/ /", "/g')"]}}
SEND
}

function ksizing {
    echo "-o initial_window_width=${COLUMNS}c -o initial_window_height=${LINES}c" > ${KTERM_DIR}/size.$$.${KTERM_NAME}
}
trap 'ksizing' WINCH
function kcleanup {
    rm -f ${KTERM_DIR}/size.$$.${KTERM_NAME}
}
trap 'kcleanup' EXIT

function kphrase {
    echo $(kadjectives | rword)"-"$(kfeelings | rword)
}
function rword {
    cat - > /tmp/words.$$
    head -$(($RANDOM % $(wc -l /tmp/words.$$ | awk '{print $1}'))) /tmp/words.$$ | tail -1
    rm /tmp/words.$$
}

function kadjectives {
    cat - <<\EOF | fmt -1
agile agree alert alive allow aloha amaze ample amply amuse angel
ardor aware bless bliss bloom bonus champ charm clean clear dandy dream
drive eager enjoy extra faith fancy focus giddy glory grace grand
great guide happy heart hello honor human humor inner jolly 
laugh learn light logic loyal lucky magic major mench mercy merit moved
noble order peace pious power pride proto proud quiet ready relax renew
scope serve shine skill sleep smart smile space spark start still study
style sweet teach thank touch trust truth unity valid value vigor
water whole worth yearn young youth yugen yummy zappy zesty zippy
EOF
}

function kfeelings {
    cat - <<\EOF | fmt -1
acceptance admiration adoration affection agreeable amazement amusement anticipation assertive assured
astonishment attachment attraction bewitched bliss calculating calm caring cautious charmed
cheerful closeness compassion complacent compliant composed content contentment delighted desire
eager earnest ecstasy ecstatic elation enjoyment enraptured enthralled enthusiasm equanimity
euphoria excited extroverted exuberant ferocity flummoxed fondness generous glad happiness
happy hysteria infatuated interested introverted jaded jolliness jolly joviality joy
jubilation keen kind kindhearted kindly laidback longing love merry modesty
nirvana open optimism outgoing passion passive peaceful pensive placid pleased
pride proud queasy quiet quirky rapture relief sardonic satisfaction sentimentality
serenity shock smug spellbound stoical subdued surprise sympathy tenderness timidity
tranquil triumphant trust vanity vigilance vivacious watchfulness wonder zeal zest
EOF
}

[o-sdn-o]

You might consider using the TUI desktop environment netxs-group/VTM#13.

I think that in the near future this will allow you to do what is discussed here. You can test how it works right now via ssh or watch the video https://youtu.be/fLumnSctakY.

You can also test the multi-seat/user functionality by making multiple simultaneous ssh-connections to the demo server ssh vtm@netxs.online.

[anicolao]

Thanks for the suggestion, as that might possibly work for others.

However it is pretty much the exact opposite of what I want, which is small tools that combine with each other arbitrarily. I don't want my terminal to be my window manager (and if I did, I already have tmux and screen to choose between).

[bbourgoine]

I've no opinion on local multiplexers, but I make heavy use of remote ones.

Rather than re-inventing the wheel, forking tmux, etc..., would a somewhat less drastic solution be something like iTerm2's tmux integration?

For non-OSX folks, iTerm2 has this nifty little feature that lets you ssh $user@$host 'tmux -CC attach', and you get native local iTerm2 windows and tabs from your remote tmux session. If you haven't used it before, it's glorious (for those of us who work on remote systems all day, anyway), and is the one thing that ties me to iTerm2 at the monment, rather than a much faster option like kitty.

As an example, when I attach to my usual work session, I get three native windows, each with three native tabs. I can detach from the tmux session, and all three windows go away. Re-attach, and all three appear. CMD-N or CMD-T asks if I want to open a tmux window/tab or a local one (though mixing local tabs and tmux tabs is rather fiddly - I tend to try to avoid that)

I'm not sure how viable something like that is to implement from a development perspective, though.

[anicolao]

@bbourgoine what you are asking for is relatively trivial to implement on top of the shell script I posted above. The main addition you need is a record of which terminals you want open on your remote client and where on the screen you want them. I personally would implement this with a local script that would start the session and open all the windows (which will re-use them if the remote session exists, and create them if not). Note that you have to position the windows appropriately on each client and use the clients' window managers for that; only the #cols and #rows is controlled by the remote session, but not the position.

[greneholt]

It may be worth mentioning that wezterm has a feature similar to this. It runs a multiplexing daemon on a server, and all new tabs/splits in a window are started as persistent sessions on the server. Unfortunately, I have not been able to get this feature to work for me yet, and I greatly prefer the capabilities and performance of kitty.

[basbebe]

I would also welcome a solution to this. I love using kitty one everything local on my Mac OS machine but for SSH I still use iTerm because of it's tmux integration. Kitty isn't in the FreeBSD ports tree and I'm still unsure about the implication of replacing tmux with kitty on a remote server.

[ghost]

I have explained before why multiplexers are a horrible hack.

Wow! I have been using multiplexers for over 20 years (physical ones before that) and would never suffer the hubris to insult them like that.

[kovidgoyal]

On Tue, Feb 09, 2021 at 10:41:45PM -0800, Darkermatter wrote:

I have explained before why multiplexers are a horrible hack.

Wow! I have been using multiplexers for over 20 years (physical ones before that) and would never suffer the hubris to insult them like that.

So, you using something for 20 years means it is not a horrible hack?? What brand of logic is this?

Instead of making content free posts and spamming people's inboxes, if you have something substantive to say, try responding to my actual criticisms of terminal multiplexers, posted above, in https://github.com/kovidgoyal/kitty/issues/391#issuecomment-638320745

[metalelf0]

They might be a "horrible hack", but right now they are the only way to have persistent sessions inside terminals, yours included. Criticism is ok, as far as there is a viable alternative that answers the same user needs. If I need to close kitty for any reason (e.g. change font), or I need to connect from another device on the same network and keep working, right now I need to use those "horrible hacks", otherwise I have to kill all my running processes and start them over. These two scenarios are fairly common in my daily work and that's why I'm using tmux inside kitty.

[kovidgoyal]

On Tue, Feb 09, 2021 at 11:00:56PM -0800, Andrea Schiavini wrote:

They might be a "horrible hack", but right now they are the only way to have persistent sessions inside terminals, yours included. Criticism is ok, as far as there is a viable alternative that answers the same user needs. If I need to close kitty for any reason (e.g. change font), or I need to connect from another device on the same network and keep working, right now I need to use those "horrible hacks", otherwise I have to kill all my running processes and start them over. These two scenarios are fairly common in my daily work and that's why I'm using tmux inside kitty.

So use the horrible hacks, no one is stopping you. Doesn't change the fact that they are horrible hacks, and should be called horrible hacks.

[NikoKS]

Sharing my current solution to the problem: kitty-vim-tmux-navigator

This will at least make navigation between tmux and Kitty seamless.

Until the ideas in this thread is implemented, I think this is the best option for us.

[EvanCarroll]

Why are we defending tmux here? Don't distract from Kovid with this apologia. He's 30 mg of adderall and a midnight hack session away from changing the way you do everything again. It'll come. Be the wind in the sail, not the anchor. He says tmux is a stupid lame hack that kills children, then so be it. He's probably right. He is the subject matter expert.

tmux to the ash heap of history, go now. Bad hack. Good riddance

[wjkoh]

A persistent connection can be done by having two kitty terminals running local and remote and mirroring those two kitty terminals over network, no? The mirroring part is the missing piece and I'm not sure if the author is interested in or not, though.

[singalen]

This is my ssh (to be precise, et) session in iTerm + tmux control mode. I can:

• use OS native hotkeys and mouse to navigate tmux panes. I don't have to learn specific hotkeys that conflict with my current setup.
• disconnect from it on one computer and continue on another one.
• save the session, reboot the target computer, and restore the current directories and command history.

I'm very interested, what other software combinations do this? These, and not a colored underlines, are a features that people need in their tools.

[greneholt]

You have your tools that meet your needs. Others, like myself, would prefer to avoid tmux so that all the modern features in Kitty are actually usable by shell programs, such as synchronous screen updates, clipboard access, and working keyboard modifiers other than alt. Everyone can win here, there is no need to argue about which tool is better.

[almereyda]

I'm very interested, what other software combinations do this?

Please have a look at:

• https://github.com/gravitational/teleport/
• https://github.com/moul/sshportal

You could then integrate this with kitty's native window, tab and pane preset configuration.

The useful state of a session, for me basically e.g. windows, tabs and panes, scrollback buffers and command history, should be diverted elsewhere as declarative configuration and event logs, if we want to keep our systems composable and following a functional/unixoid stdin > process > stdout pattern. Such a "stateless" approach to our recurring connections helps us not to worry about losing history, while still profiting from the versatility of adaptive views on and into our infrastructures.

The more we move into direction of infrastructure-as-code cloud environments, direct root access to individual machines and their state becomes less and less important - think the cat-and-cattle discussion - because these side effects are handled by the cluster abstraction. Meaning multiplexing shell sessions becomes also less and less important, when we primarily talk to our infrastructure via declarative configuration in git and APIs.

[greneholt]

Terminals are stateful output devices. There is no way around that, although in extremely simple use cases this fact can sometimes be ignored. For the use case that this issue is intended to solve, namely a persistent session on a remote development machine, ignoring state would be extremely counter-productive.

I use a Mac laptop as a "thin client" of sorts to a personal Linux server where I do all my real work (editing files, interacting with git, running simulations). Persistent, resume-able, stateful terminal sessions are necessary for this model.

[test-account-0]

clipboard access

I might not understand this like the other two things but there is OSC 52, you can use it with tmux+kitty already.

[singalen]

Others, like myself, would prefer to avoid tmux so that all the modern features in Kitty are actually usable by shell programs, such as synchronous screen updates, clipboard access, and working keyboard modifiers other than alt. Everyone can win here, there is no need to argue about which tool is better.

In order for everybody to win, some client needs to support all of the features. I came here searching for a terminal client that can do tmux control mode in Linux, but looks like kitty is a lost cause. I can understand the unwillingess of kernel/system programmers to implement features that go against the current design; in kernel space, performance, correctness and consistency are critical. I can not understand the fear to spend a few extra CPU cycles to implement a frequently requested feature when it comes to userspace.

[EvanCarroll]

Most of us probably use tiling window managers. Have you considered it? What advantage does your tmux provide other than the ability to connect remotely to the multiplexer? Locally I can't see any advantage if you have tiling wm. So for me, and probably many others it's rather useless. We get this functionality, and it works with browsers and other gui apps.

Check out Yubai if you're on OSX. i3 or sway if you're on Linux.

All the terminals in this video are Kitty.

[equaeghe]

Most of us probably use tiling window managers.

That is an unsubstantiated assumption. Even if you are right that most are, what does it matter, because certainly not all are? The kitty developer may decide in the end that implementing tmux-like functionality for kitty is not worth it from their point of view. But that still doesn't mean that the need of such functionality multiple people are expressing throughout this issue is misguided.

 What advantage does your tmux provide other than the ability to connect remotely to the multiplexer?

For me, see the original message in this issue report: Persistence, i.e., resuming after a WM crash, for example. That, in combination with multiplexing.

[lkhphuc]

I guess this must have been said somewhere above, but for those who want persistent session and multiplexer without tmux:

• abduco give you persistent session, local or remote what not.
• dvtm give you multiplexer, local or remote what not. These two command line tools are minimalistic, "suckless", does one thing and does it well. You would probably want to give it a try.

Currently I use dvtm on remote and kitty's window/tab for local, if the idea in this issue is implement then I can ditch dvtm for good, though it's not a bad software, it's just one less thing to remember and configure.

[kovidgoyal]

This issue is about implementing a daemon for persistence of sessions in kitty. It is not about the merits or otherwise of tmux. If for some absurd reason you are wedded to tmux, then good luck to you. kitty is never going to integrate tmux specific features, as tmux and terminal multiplexers in general are an anti pattern. Someday, I will get around to implementing a daemon for persistence of tty sessions in kitty. That will be more robust, feature-rich and efficient than any terminal multiplexer.

Kindly restrict discussion on this issue to the design and features of such a daemon. In particular, if you are willing to work on such a daemon, or you have ideas about how it should work, I am happy to hear from you, otherwise, please stop spamming my inbox.

[dankamongmen]

They are of course sadly neglected and have a lot of legacy baggage it would be good to get rid of cough ncurses cough.

a brighter day is coming, my friend =] if you have any suggestions to give regarding general/detailed notcurses design, i would continue to appreciate your learned commentary. i'm really hoping it resolves a lot of the pain points and annoyances of ncurses.

[Aneurin]

tmux and terminal multiplexers in general are an anti pattern

You keep repeating this ad nauseam despite offering no evidence for your outlandish assertion, while repeatedly demonstrating no comprehension of what whey do nor what they're for, along with an absolute pig-headed unwilingness to learn.

I'm literally shaking with anger at your reprehensible behaviour in this thread. Just delete this issue entirely; it's poison.

[kovidgoyal]

tmux and terminal multiplexers in general are an anti pattern

You keep repeating this ad nauseam despite offering no evidence for your outlandish assertion, while repeatedly demonstrating no comprehension of what whey do nor what they're for, along with an absolute pig-headed unwilingness to learn.

I'm literally shaking with anger at your reprehensible behaviour in this thread. Just delete this issue entirely; it's poison.

I suggest you first learn to read. The learn to reason. The go soak your head.

[Mic92]

This is how wezterm solved this feature: https://wezfurlong.org/wezterm/multiplexing.html It also works with remote hosts/serial connections and unix sockets.

[ReubenM]

kitty is never going to integrate tmux specific features, as tmux and terminal multiplexers in general are an anti pattern.

I do agree it is an anti-pattern for local terminals. But the one place I find multiplexing very useful is in shared remote sessions. I'm often using remote shared terminal sessions for tech support and trouble shooting so that all parties connected can observe what is going on. (Usually use tmate for this) Often I need more than one shell instance, and it is handy to be able to be able to do that directly within the shared session. Without the multiplexing, all connected parties would have to manually add a new connection for each new shell instance. Not overly complex, but tedious.

The tabs feature within kitty would be sufficient for this purpose, but for that to work it would (if I understand correctly) need to be something managed by the persistence daemon.

Bonus points if the persistence daemon could integrate with xterm.js or something similar for remote web browser based connections similar to tmate. My employer uses ms-teams quite a bit, and being able to add a website tab (web based tmate session) to a channel is perfect for managers who may know nothing about terminals but still want to observe what is going on. Probably beyond the scope of what the kitty project is willing to take on, but I dare to dream.

[almereyda]

As it wasn't already mentioned here before, and wezterm already made its notable appearance in this thread, and because of kitty decidedly never being a terminal multiplexer, I am mentioning https://github.com/zellij-org/zellij

Zellij allows you to implement a terminal multiplexer that is not tmux or screen independent of the terminal emulator that you are using.

[ghost]

I think this would be a great feature and selling point if it could result in lower start up times and memory consumption per "os window". Not that I think that Kitty is problematic in this regard (especially startup, while noticeably slower than urxvt, is still instantaneous as far as I 'm concerned), but IMO it would be a solid technical improvement anyway.

Kitty's splits and tabs eat up much less memory than new windows already, but people that use tiling window managers might prefer to manage these through their wm, especially if it also supports tabs, like i3 or sway.

[trygveaa]

I think this would be a great feature and selling point if it could result in lower start up times and memory consumption per "os window". Not that I think that Kitty is problematic in this regard (especially startup, while noticeably slower than urxvt, is still instantaneous as far as I 'm concerned), but IMO it would be a solid technical improvement anyway.

kitty already has a solution for that, the --single-instance option.

[kovidgoyal]

This thread is now an unmitigated waste of my time.