Good, one of my goals with kitty is to obviate the need for tmux like hacks (they waste CPU cycles and causes lots of rendering bugs).

However for resuming sessions, I'm not sure what you mean exactly. kitty can define sessions to run startup programs and set windows/tabs etc. For resuming running programs, there are lots of questions:

1. Does it work locally only or over ssh as well
2. Does it suspend the running programs while the UI is closed or does it buffer the output waiting for a UI to reconnect. If the latter, does it limit the size of the buffer?
3. What does close the UI mean? Hide the windows? How is that significantly different from just using minimize?

Lets consider:

• kittyd: the daemon component which is responsable for forking child processes and sending stream of data to the UI component;
• kitty: the UI component which is responsable for drawing the layout and rendering;

The ideal feature would have the following:

1. Attach locally or to remote server

I can connect to a remote server and have a kitty session already started there, to which I can attach;
So, it can be ran over ssh.
I'm thinking about passing kittyd as some sort of parameter to kitty. This way, I can specify the "provider" for the UI:

$kitty --daemon /usr/bin/kittyd

$kitty --daemon ssh://mihaicristiantanase@server.com:/usr/bin/kittyd

I'm not sure what this means or if it's even possible, but I hope you see where I'm going with this. The idea I have in mind looks something like:

# # # # # # # # # # # # # # # # # # #         # # # # # # # # # # # # # # # # # # # 
#                                   #         #                                   #
#   kittyd     <--------    kitty   #         #   kittyd     <--------    kitty   #
#    ^                              #         #                                   #
#    |                              #         #                                   #
# # RemoteServer1 # # # # # # # # # #         # # RemoteServer2 # # # # # # # # # # 
     |
     +------------------------+
                              |
# # # # # # # # # # # # # # # # # # # 
#                             |     #
#                           kitty   #
#                                   #
#                                   #
# # LocalHost # # # # # # # # # # # # 

RemoteServer1's kittyd is "provider" for both itself and LocalHost.
LocalHost does not have kittyd started.
RemoteServer2's kittyd is "provider" only for itself.

2. Killing (closing) kitty should not kill kittyd

So, the running programs should not be suspended when UI is killed. The output should be kept limited to the same limit current kitty implementation uses and should be sent to the UI when it attaches to the session again.
Probably this redirecting of output from daemon to UI might cause lagging and should be investigated first.

3. Multiple sessions can be defined in one kittyd

When kitty attaches to kittyd, it can specify which available session should be rendered.

4. kittyd should have a one-to-many relationship with kitty

One kittyd should be able to provide stream of data to multiple attached kitty(s).

5. kitty should have a one-to-one relationship with kittyd

One kitty can only attached to one kittyd.

There are issues with that.

1. There is no limit to the output in kitty, old output is simply discarded when new output is received and the scrollback buffer is full. However the daemon cannot do that because terminals are actually giant state machines with lots of internal state, that is affected by the various terminal escape codes that can be present in the output. So a daemon would need to either preserve all output or maintain its own internal terminal with no rendering, at which point it is basically a terminal emulator itself.

2. While I can sort of see the use case for remote connections, I dont really see why one needs to all this for local connections? Simply minimize kitty instead of closing it, to achieve exactly the same effect. When minimized no rendering happens, and whenever you want to resume, simply un-minimze.

Regarding point 2,

While I can sort of see the use case for remote connections, I dont really see why one needs to all this for local connections

One of the main reasons tmux is useful for local connections is the ability to recover from accidentally closing the terminal window instead of minimizing or hiding it (the MacOS kind of hiding). That ends up saving me from losing work on a frequent basis.

Another reason tmux is useful for local connections is the easy ability to switch between working locally and remotely. If I've been working in a tmux session at my work machine, it's very easy to go home and resume the same session from my laptop. It is harder to add a session you started outside of tmux to a tmux session after the fact (though there do exist tools, e.g. https://github.com/nelhage/reptyr, to do so).

Also, not all window managers support easy minimization (in particular, I use i3, which does not have minimization as far as I know. There's the scratchpad, but this is not quite the same imho).

@sheriferson A simple confirm on close would take care of that.

@wbthomason I use i3 as well, and I simply move a terminal to an unused desktop when I want it out of the way, that is exactly the same as minimizing.

@kovidgoyal Yep - my continued use of tmux is much more due to the first reason I mentioned than that.

Well, yeah, like I said, I can see the use for remote connections, local not so much. Of course if I were ever to implement support for remote connections, you could always use the daemon locally as well.

I'll leave it open as an enhancement, but as this is a fairly large job and I have no use for it personally, unless someone steps up, its not likely to get implemented any time soon.

Thanks for keeping the idea open.
I've being relying on the user-experience of tmux so much that a solution in which a terminal emulator can replicate the behavior I'm used to, but without the overhead, is more than attractive.

For now, I'll keep using tmux with it's statusbar hidden :) .

tmux is also useful for sharing windows between terminal instances, through link-window. In kitty terms, that would mean sharing/mirroring tabs. For example, I like to have weechat available on all of the terminals I spread across virtual desktops. Not sure if that requires going so far as a daemon for kitty, but it's a feature I'd like to see.

Another thing is that, unlike kitty sessions (as far as I can tell), a tmux multi-session setup doesn't commit the user to actually opening all of the possible terminals. You can open and close them at will. With kitty right now, it seems that there has to be an open terminal window for any set of tabs you configure.

@neverfox Wouldn't the right way to have a particular window available on all desktops be to make it sticky in your window manager? Why use tmux for that? In any case, a daemon can easily allow read-only access to a particular window by multiple clients.

@kovidgoyal It's not a particular OS window that I want to share across desktops, but a particular tmux window (the equivalent to a kitty tab). For example, I have a terminal open on each of three desktops. Each might have a custom set of tabs on it. I like one of those tabs to be, say, weechat (the same weechat, as weechat doesn't by default like multiple instances running):

• Desktop 1
  • Terminal Window 1 (tmux session A)
    • Session A Window 1 (zsh ~)
    • Session A Window 2 (mutt)
    • Session C Window 1 (weechat - linked)
• Desktop 2
  • Terminal Window 2 (tmux session B)
    • Session B Window 1 (zsh ~/work)
    • Session C Window 1 (weechat - linked)

A window manager can do nothing for me here, because it's state internal to an OS window. Tmux lets me do this, though its session restore capabilities are lacking in preserving that state, which is annoying. The way states are serialized doesn't record that the window was linked and so they get restored as separate windows.

@kovidgoyal To combat the "the daemon is a TE" thing, you could add an option to kitty which would prevent it from rendering and invoke daemon-specific logic.

Another scenario I use tmux locally for is to be able to close kitty and reopen it with a new configuration, without losing my open windows. E.g., when I want to change the current font, and I have something like 5-6 panes open, I edit the kitty config file, detach my running tmux instance, restart kitty and reattach back to my tmux session. I know I can change the font size, but I still haven't found a way to change the font face.

While I can sort of see the use case for remote connections, I dont really see why one needs to all this for local connections? Simply minimize kitty instead of closing it, to achieve exactly the same effect. When minimized no rendering happens, and whenever you want to resume, simply un-minimze.

I may be misunderstanding this, but as far as I am concerned, an URXVT daemon for example, has a major use case for local usage, since It effectively becomes the main terminal and the children/clients become very minimal as a result.
The result is that the terminal start up time is significantly improved (something that I've found Kitty suffers from, compared to lets say Alacritty (though that has significantly more problems on its own)

It also reduces ram usage, for the primary system, which is quite significant if you're running half a dozen terminals.
Personally, I take a lot of issues with the URXVT project, but that daemon is something I've been looking for, for a long time now.

Have you tried --single-instance? Also, make sure the slow start up is not actually caused by your shell configs.

For me:

time repeat 100 kitty sh -c exit:      24s (240ms startup time)
time repeat 100 kitty -1 sh -c exit:   10s (100ms startup time)

Have you tried --single-instance? Also, make sure the slow start up is not actually caused by your shell configs.

I'm not sure how I managed to overlook that, this is exactly what I've been looking for.
Execution time ended up going from 1.30-1.55 seconds to 3-5ms, so an odd ~30 fold improvement.
Shell seems to be irrelevant. This was tested with default configuration as well.

This is the exact functionality I wanted from a daemon, so consider my use-case fulfilled.

@VGrol Just FYI, a 1.3s startup time is not normal. On my four year old laptop kitty starts up in 0.2 secs and on my dev machine in 0.1 secs. There have been a few reports of slow startups on some linux systems, but no one has ever bothered to investigate, and since I cannot replicate, I cannot investigate.

Just FYI, a 1.3s startup time is not normal. On my four year old laptop kitty starts up in 0.2 secs and on my dev machine in 0.1 secs. There have been a few reports of slow startups on some linux systems, but no one has ever bothered to investigate, and since I cannot replicate, I cannot investigate.

I kind of figured that much, but I don't really know what to tell you.
Other terminals have a 'normal' start up time for me and the system is actually quite high end.
What do you need me to test? I'll open a separate issue for it if you'd like me to explore it further.

I noticed that my super old, modded laptop doesn't have those startup issues, yet it runs a nearly identical environment, so I'd almost think It'd be related to hardware boogaloo.

Yeah feel free to open a separate issue -- note that you have to be willing to run kitty from source and make some simple code modifications to investigate.

@kovidgoyal:
First of all, I just discovered kitty and it looks positively awesome!! Thanks for your effort in building it!!

Taking reference to your message from Mar 16: Personally I would love to have something that could completely replace tmux, while being actually fast to render:

• Stays alive even if my UI crashes
• Works over ssh (or maybe even mosh)
• Runs processes in the background when I terminate all UI related features

I could imagine a iterm style tmux integration, but I probably wouldn't mind installing a headless kitty server on my servers :)

The main advantage of tmux and screen besides remote sessions was for me always the independence of the window system. I can kill everything related to Xorg or Wayland and come back reattach to the session as if nothing happened.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

This thread is now an unmitigated waste of my time.