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://[email protected]:/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.

[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 [email protected].

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