Should autoquit be enabled by default?

[joelim-work]

Currently the autoquit option (server automatically quits when there are no clients left) is disabled by default.

However it has been suggested to enable it by default, see #912 (comment) and #1761 (comment).

---

Pros:

• New users may be surprised to see a server instance of lf being left behind, and enabling autoquit by default prevents that from happening.
• This is similar to how the tmux server works by default (set using the exit-empty option).

Cons:

• This is a breaking change, and may require users to update their configuration.
• Some users may not want to start the server every time lf is started, especially if it causes delays.

[ilyagr]

Everyone should try inserting set autoquit in their config and see if they notice any problems.

---

I don't have a clear opinion, but it turns out that setting autoquit does affect my config by making a bug I had in it worse. The bug is #1293.

I haven't spent the time to read carefully about the workarounds, but I didn't immediately find one. Does anyone have a suggestion for how to avoid this?

Details

The problematic snippet seems to be:

cmd recol ${{
    w=$(tput cols)
    if [ $w -le 30 ]; then
        set nopreview
        lf -remote "send $id set ratios 1"
    elif [ $w -le 50 ]; then
        lf -remote "send $id set ratios 1:1"
    elif [ $w -le 65 ]; then
        lf -remote "send $id set ratios 3:4"
    elif [ $w -le 95 ]; then  # Was 160
        lf -remote "send $id set ratios 2:3:4"
        set preview
    else
        lf -remote "send $id set ratios 2:2:3:4"
        set preview
    fi
}}

recol

On the first run of lf, the recol command results in this message:

$ lf
listen: send: no such client id is connected

Without autoquit, this only happens once. If I put set autoquit in the config, this happens every time lf is started (if the server isn't running).

[joelim-work]

So I searched through the past issues and apparently this has been reported before in #495.

The main problem is that until the client successfully connects to the server and sends a conn <id> message to register itself, any kind of lf -remote command is not going to work. Regarding your idea of queuing commands until the client is ready, I don't think this is a proper fix - the user would still have to wait one second (or however long the registration takes) for anything involving remote commands to actually take effect. Another option is to have lf -remote fail if the client ID lookup fails, and retry based on the exit code, but it has the same issue of forcing the user to wait until the client has registered itself.

I still think that the main issue is the fact that the client takes too long to register itself, if it has to start up the server too. The only suggestions I have (none of them are particularly great) are:

• Decrease the sleep interval (currently one second). I don't know why the current value was chosen, but decreasing it will mean potentially more spam in the log file as the client fails to connect to the server. That might not be such a big problem however.
• Start the server beforehand (i.e. as part of your system startup). But then this suggests that the server should never quit and that autoquit shouldn't be enabled by default.
• Look at other alternatives for scripting dynamic configuration (e.g. using Lua), which don't require a server. But this is such a large change that it would probably be better to start from scratch (similar to Neovim), and then there is probably no point doing that either because you might as well use yazi instead.

[DusanLesan]

I did think queue is not a good solution, but I was not able to think of anything else. I am willing to run lf with reduced interval to see if I ever bump into any issues. As for logs about failed connection, can they be ignored first n times?

[joelim-work]

I did a very quick test, changing the initial retry sleep to 100 milliseconds (as opposed to 1 millisecond in the diff I posted earlier) seems to be sufficiently quick enough for user-mapped commands which call lf -remote, without spamming the log too much. I don't think a user press any keys that quickly immediately after opening lf.

But an on-init hook would still be required for anything that needs to be run automatically on startup.

[DusanLesan]

Do you want me to try it as well? I can keep ruining it for a while to see if there are any issues in regular use. Do you want to keep increasing duration exponentially?

[joelim-work]

Well if you take a look at the code, the initial sleep duration is one second when retrying, and then is doubled each time afterwards. But feel free to experiment with the initial duration and the on-init hook, and if it works I might consider submitting it as an actual PR.

But even then I don't know if I will end up changing the default for autoquit at this rate. So far there have only been two votes which is a very small sample size.