Open m-kru opened 3 years ago
I remember this proposal being considered by @mawww years ago, but it never happened.
I'm not opposed to the idea, but the thing is: would that fix a real problem? It makes sense that the client wouldn't connect to a suspended server, since the process cannot call accept()
.
If you know the server is suspended, resume it, connect an additional client to it then quit the one that started it. If you don't and often find yourself in that situation as a result of your workflow, maybe using a shell alias to start a background session would be better?
I think the server isn't already automatically forked to the background to limit side effects on running kak
. The user expects one process to be run, without anything spawning in the background, similarly to other editors — and that works even in environments that don't have job control. Alternate behaviours are opt-in explicitly via the -d
and -s
flags.
Ok, I have an idea. Maybe the best solution would be to add an option for forcing server forking on startup? For example providing -sf
instead of -s
would lead to that behavior?
You could just say kak -s tmp &
. Same number of keystrokes as kak -sf tmp
, more consistent with other Unix applications.
@Screwtapello what does exactly kak -s tmp &
do on your system? It looks like it is not what I want to achieve. The editor behavior is broken when you add &
at the end to make the command run in the background.
kak -d -s tmp &
runs a pure server in the background, you can then connect clients to it as you want.
kak -d -s tmp & kak -c tmp
would launch an initial client connected to that server.
(EDIT: what @krobelus said)
That should be kak -d -s tmp &
otherwise it will launch a client as well (which cannot take control of the terminal).
Open 2 terminal emulators. In both
cd tmp
. In the first one runkak -s tmp foo
and stop the job with<C-z>
. In the second one runkak -c tmp
Result - the client session is also sopped.One needs to restore the server session. After the first restoration the server is forked to the background and the problem disappears.
My proposal: Always fork server to background at server session startup.