[v3 spec] Purpose of `slow_threshold`?

[Torsteinws]

Can you please help me understand the use case of slow_threshold?
I don't quite understand the idea behind it.

Who is it intended for? Backend devs or end users?

[geodimm]

Hi @Torsteinws ,

It came about because of my initial feedback: #488 (comment)

The naive implementation of the ghostty backend simply calls the osascript binary and that takes more than a 100ms which was a hardcoded threshold in the core which lead to a warning message being emitted every time a user leaves Neovim. The purpose is for backend users to fine-tune it and set a better default based on the performance of the terminal/multiplexer. However, I think it's also useful for end users to calibrate as the speed is also dependent on the machine itself. I'm happy to submit that maybe exposing this to the user is too much and perhaps we could leave it only the backend devs to set a value.

[Torsteinws]

I kinda feel like this should be a config in core instead of having it in the protocol. Maybe something like:

return {
  "smart-splits-nvim/smart-splits.nvim",
  opts = {
    diagnostic = {
      enable = true,        -- Defaults to false
      slow_threshold = 200, -- Defaults to 100ms (or something else?)
    }
  },
}

Then it is up to the backend dev to enable the diagnostic.

This also allows the dev to benchmark all commands by setting slow_threshold = 0, which could be useful.

[mrjones2014]

Yeah on second look I think I agree it doesn’t really belong in the protocol.

I think I like your approach @Torsteinws, like you said you can set it to 0 for testing, or end users can increase it if using a slower backend.

I’ll put up a PR in a bit.

[Torsteinws]

I think it should default to be turned off though. I believe most users don't want to see this notification.

Devs and tinkerers will find the config and turn it on if they want to.

[mrjones2014]

Not sure why #498 didn't auto-close this 🤔