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!

[kovidgoyal]

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?

[mihaicristiantanase]

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.

[kovidgoyal]

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.

[sheriferson]

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.

[wbthomason]

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

[kovidgoyal]

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

[wbthomason]

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

[kovidgoyal]

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.

[mihaicristiantanase]

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 :) .

[neverfox]

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.

[kovidgoyal]

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

[neverfox]

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

[anirudhb]

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

[metalelf0]

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.

[VGrol]

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.

[maximbaz]

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)

[VGrol]

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.

[kovidgoyal]

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

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

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.

[kovidgoyal]

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.

[koraa]

@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 :)

[nkoehring]

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.

[grst]

For me, this would be a killer feature! I rely a lot on tmux to keep session alive when working on a remote server (when ssh interrupts, or simply continuing work on the next day). Using tmux within kitty prevents cool features to work, for that I would like to use kitty in the first place (see, e.g. #413).

[nertpinx]

I came here for the remote-sharing. Wouldn't this be possible by two instances sharing the same data that kitty can dump and replay? Definitely not a perfect solution, but it could be a good start, right?

@kovidgoyal I'll try to find some time to look at the code, don't promise anything (except ongoing funding :wink:), but I would appreciate any pointers (maybe others as well in case they can dig into it). Does the above make sense or is that completely wrong presumption? Thanks.

[nicoulaj]

Another way could be to integrate with tmux via its control mode.

This would allow to attach a tmux session and handle the rendering of tabs/panes/windows/scrollback.

This is a solution that has been considered or implemented by other terminal emulators:

• iterm2: supports it
• terminator: some contributors have been working on a patch, not merged
• tilix: has an open issue

[kovidgoyal]

@nertpinx Mostly, yes. what you basically need is to extract the parser and state machine parts of kitty into something that can be run in a daemon, then create a serialization/parsing of that state so the daemon can update re-attached clients. kitty's code is pretty modular already,. so this should not be hard. Essentially look at the Screen struct, which stores the relevant data in CPUCell and GPUCell structs.

@nicoulaj I'm afraid tmux integration is a non-starter for kitty. THe whole point of kitty and this bug report is to make terminal multiplexers obsolete.

[daniel-pfeiffer]

I need to connect to a lot of servers and need several (sudo-)shells there. Multiple ssh is a pain, because we must go through Balabit. The only available remote multiplexer is screen. It would be way cool if that would invisibly do the work, while kitty controls it and pretends everything were its own tabs and windows.

[equaeghe]

Could dtach play a role here?

[atsepkov]

On similar note to last poster, instead of trying to replicate tmux functionality, why not use a tool like dtach or the more modern abduco for session management?

[kovidgoyal]

The main limitations for tools like dtach would be (as I understand it):

1) They store all output, so reconnecting can potentially be very slow as all output has to be processed at once. In contrast tmux/kitty would maintain current terminal state and a configurable amount of scrollback

2) They only maintain state for a single prgram at a time, whereas tmux and a potential kitty replacement for it would do it for all programs and also save state for current layout/tabs/windows etc.

[pjz]

My solution is to use xpra to run kitty remotely, so it can be detached/reattached, stays running, etc. I've just started using it, but feel that kitty+xpra may replace screen for me, while also allowing things like icat to be used remotely. (edit: fixed link per @Luflosi) (subsequent report on kitty+xpra): Kitty+xpra ended up way too bandwidth intensive and latency sensitive for continued use. I'm back to kitty+ssh+tmux.

[Luflosi]

The link is broken. It should be https://xpra.org/.

[singalen]

Maybe tmux control mode is not that much against kitty goals?

It is not about window tiling, panel management is done by the client. Control mode is about having a persistent (multi-panel) session that survives the reboot of the client computer, and it uses the native panels of your GUI. Using the control mode in iTerm, I have never used tmux keyboard commands, I don't even have access to them.

Control mode definitely obsoletes the tiling part of tmux, and is somewhat close to the "Remote control" feature.

[rlyeh]

+1 to @singalen 's analysis. tmux conrol mode is complementary to kitty for some critical use cases, not in conflict with it.

tmux's rendering and keyboard commands aren't really relevant to how it works in concert with iterm2 in control mode. In fact, bypassing them (as they can on os x) is one reason linux users want a terminal emulator that can integrate with tmux.

tmux can be nice on your local computer. It can be an absolute lifesaver when you are connected into a remote machine, especially if it's a remote machine, vm, or container where you can't install software (using tmux securely is well understood). Connections drop for all sorts of reasons and the ability to survive the loss of a connection ends up being far more important than any loss of performance from the buffering of output. And it's not like this would have any impact on people who weren't using tmux.

[BourgeoisBear]

@kovidgoyal, a lot of us use tmux not so much as a terminal multiplexer, but as a session-preserver. It lets us attach/detach from a running session, and even share a session as a sort of poor man's VNC.

"Control Mode" is something Nachman added to tmux for iTerm2. With Control Mode integration, Kitty would get session preservation for free. It would also be a better tmux than tmux, since tmux is constrained by legacy tty and command-escaping limitations, but Kitty isn't.

https://github.com/tmux/tmux/wiki/Control-Mode

I'd be glad to take a stab at it as long as I have your blessing. 🙏

[test-account-0]

I rely on tmux for many years. It's not something I need to replace. It's great. It's amazing. One of the best tools I've ever used. Also - new features it's getting are the ones I wanted but didn't know about it. :)

Not sure if it's possible. But if I still could use tmux key bindings in kitty with prettier gui than tmux and connect to remote or local tmux session (or both!) - that would be SOMETHING.

[kanyck]

First of all I must stress that kitty is positively awesome. Great software, thanks! However, I'm lost. I've read all this kitty/tmux stuff here and now am lost even more))) What I really use tmux for is just keeping sessions, i.e. ability to detach a running session with ability to reconnect later without killing running apps. So I'm able to start a long process and detach. I couldn't make kitty to play nice with tmux (or tmux to play nice with kitty). That's the only thing that keeps me from fully abandoning lilyterm in favor of kitty. Any suggestions? Thanks!

[jhrmnn]

@kanyck If you encounter any odd behavior when using Tmux in Kitty, probably file another issue. This issue is not about Tmux being able to run in Kitty (which should be no problem in principle, and I have been doing it without problems in practice for two years now). It is actually not at all about Tmux, Tmux was just used to describe the desired behavior of Kitty by the OP. Some people then mentioned that Kitty could support the Tmux control mode, but that is yet another story. The ordinary running of Tmux in Kitty should cause no problems, and if it does, it is an issue unrelated to this one

[test-account-0]

First of all I must stress that kitty is positively awesome. Great software, thanks! However, I'm lost. I've read all this kitty/tmux stuff here and now am lost even more))) What I really use tmux for is just keeping sessions, i.e. ability to detach a running session with ability to reconnect later without killing running apps. So I'm able to start a long process and detach. I couldn't make kitty to play nice with tmux (or tmux to play nice with kitty). That's the only thing that keeps me from fully abandoning lilyterm in favor of kitty. Any suggestions? Thanks!

these are the lines from kitty.conf it seems I have changed from the default values:

cursor #000000
cursor_text_color background
cursor_blink_interval 0
scrollback_lines 0
mouse_hide_wait 0
rectangle_select_modifiers no
enable_audio_bell no
hide_window_decorations yes
background #ffff99
foreground #000000
selection_foreground #ffff99
selection_background #000000
# this is crazy, by default it appends copied stuff to what You have currently in clipboard
clipboard_control write-clipboard write-primary no-append
term xterm-256color

Also I think You need version 0.17.4 to get scrolling with the mouse wheel to work.

This issue is I think about reimplementing tmux. Not sure why.

[kanyck]

@jhrmnn Sorry I broke into the wrong thread. Will go soon)))

@test-account-0 Thanks! I'd borrow some... Indeed, I have a scrolling issue but the newest version in portage is 0.17.3. I thought it's a misconfiguring issue, but if upgrade solves it, it's okay.

term xterm-256color

That's the part I don't understand. I've put xterm-kitty into .terminfo/x on the server and expected this to be picked up but when I connect, I still see TERM set as tmux-256colors within the session, yet it seems to work (didn't test it thoroughly, though). At least I can use nano and create/switch tabs without apparent problems. But I can't comprehend the logic under the hood. Well, maybe it's the wrong thread to discuss this. Thanks!

[rafaeln]

One local use for tmux that people haven't mentioned so far is opening the same session on two terminals on different screens. One image is worth more than a thousand words. Here I have tmux's tab 1 open on my left monitor and tab 4 on my right monitor.

[EvanCarroll]

@rafaeln but no one is saying you shouldn't be allowed to have one kitty window open on your right monitor, and one on your left monitor. The question here is the value in the local session that unites the two.

This is a really fundamental question. It's one that people asked when Wayland was created too. What's the value in having the traditional X11 Server/Client model for local machines? The reality is that there isn't much value there. Now we're asking the same question. tmux is providing a server for clients to "attach" to.

I assume when you boil it all down, the only value that tmux has in server/client mode for local connections is that other remote users or users on your multi-user terminal can attach to it that are not the user active on that local tty.

It's obviously extremely valuable for remove connections.

[nkoehring]

@EvanCarroll I think one point you're missing here is that tmux and screen are also allowing applications to stay attached without the terminal window being open. In the last weeks for example kitty crashed from time to time taking all the running programs with it. Yesterday a kernel compilation got killed because of that after more than 20 minutes. Before kitty I had a calm mind in such a moment because I knew everything would still be running on tmux in the background and I just needtto reattach to the session.

[Luflosi]

@nkoehring You should capture a stack trace and make a bug report with the crash, so it can be fixed.

[ctrlcctrlv]

tmux can also crash. Any software can.

[equaeghe]

tmux can also crash. Any software can.

That may be true. However, I've been using it daily for a while now (5 years?), and it has never crashed or misbehaved on me. Also, tmux ‘protects’ not only against the terminal application crashing, but also anything ‘above’ (desktop environment, window manager). In practice, its background persistence feature has saved me a lot of grief. So it is not just whether software crashes, but also how often.

[jhrmnn]

Isolating the terminal into a server and client simply increases the chance that the crash does not terminate the running applications because the crash occurs in the client code—it increases resilience. Furthermore, crashes in the client part are more likely because the complexity of the GUI is usually higher than that of the server part. I mean, in general, modular architectures are more resilient to failure, or have less severe failure modes. So in my opinion the merit of the client/server architecture is clear.

I think the real equation is whether it's worth someone's (I imagine major) effort. Especially given that if such a resilience is really important to the user, they can always layer Tmux between Kitty and their applications.

[ctrlcctrlv]

I honestly think that the right thing to do in this case is not the elegant thing.

Fork tmux, call it kittymux perhaps, apply some patches fixing issues its maintainer refuses to, and call it a day. Over time, more and more patches can be applied which more closely integrate kitty and kittymux.

All the work that would need to be done in kitty to create daemonziation is not worth it. Besides, users are used to tmux, and already have configuration files for it and know its hotkeys.

[BourgeoisBear]

@ctrlcctrlv suggestion seems more like NIH. Kitty and tmux are already great at what they do. Tmux already has a feature (control mode) for tighter integration with advanced terminal emulators. Kitty already has a framework (Kittens) for exposing its advanced features.

If the Kitten API is sufficient for the features tmux control mode supplies, we may be able to achieve a tighter integration between tmux and Kitty through a Kitten--instead of changing Kitty itself. Given @kovidgoyal 's previous discussions, and his silence on this thread, he probably doesn't want tmux control mode integration inside Kitty itself.

I'll dig into how far I can get using the Kitten API. If it's not sufficient, that's probably a good opportunity to extend the Kitten API rather than adding tmux-only code to Kitty.

[kovidgoyal]

On Wed, Jun 03, 2020 at 09:04:49AM -0700, Jason Stewart wrote:

If the Kitten API is sufficient for the features tmux control mode supplies, we may be able to achieve a tighter integration between tmux and Kitty through a Kitten--instead of changing Kitty itself. Given @kovidgoyal 's previous discussions, and his silence on this thread, he probably doesn't want tmux control mode integration inside Kitty itself.

I'll dig into how far I can get using the Kitten API. If it's not sufficient, that's probably a good opportunity to extend the Kitten API rather than adding tmux-only code to Kitty.

It's not sufficient. And it's never going to be sufficient. Kittens are meant to work with new kitty windows and/or perform arbitrary transforms of its GUI layer, not alter how kitty works with parsing data-streams and responding to control codes, which is what you need for tmux control mode. That code is all pure C. Python which is what kittens use is never going to get involved, for obvious performance reasons.

And I have zero interest in tmux control mode, I have explained before why multiplexers are a horrible hack. That said if someone wants to add support for it, I wont reject a PR out of hand, though it will need to have reasonable code overhead and close to zero performance overhead to get a look in the door.