feature: Custom timeout duration (or a more obvious error message?)

[NGPONG]

Did you check the docs?

• [X] I have read all the trouble.nvim docs

Is your feature request related to a problem? Please describe.

Hey there. I noticed that currently the source is required to complete within 2000ms. This might be unfair to some slower sources, and the related code might be this part:

https://github.com/folke/trouble.nvim/blob/bf99ea71a39e322336b7f8be965f86dbf5c65540/lua/trouble/view/section.lua#L80-L82

This is a personal opinion, and it would be better if there was a user option to adjust it. However, I am not sure if this would cause any other side effects, so some discussion might be needed.

Best regards!

Describe the solution you'd like

see above

Describe alternatives you've considered

see above

Additional context

No response

[folke]

Did you actually ran in to issues with this? The items still get processed eventually. The timeout is mostly so it doesn't keep blocking other updates

[NGPONG]

Hey @folke, sorry to bother you and thank you so much for your reply !

Did you actually ran in to issues with this?

To be precise, it's both a yes and a no. In a very large repository where a single file can exceed tens of thousands of lines of code (I know this isn't very reasonable, but such codebases do exist in reality), custom source errors are causing a timeout. A key point here is that the root cause of this problem is due to user-side errors. Generally speaking, this operation does not heavily depend on the scale of the target object, but it's important to understand that ensuring any source completes the task within 2000ms is quite a stringent requirement. Even though there might be some optimization techniques to avoid it, the ultimate effect is limited. This is not about competing for some goal but simply about minimizing errors in my IDE as much as possible.

The items still get processed eventually.

There might be some misunderstanding here, at least in my case it's not like that. After the timeout, the process indeed gets handled, but the callback cb is called in a context different from what is expected. Importantly, when the callback is invoked, it doesn't pass in the result set we anticipated. From the user's side, what I can perceive is that I've waited for a period of time, but I still receive a warning error with an empty result. More deeply, the results that were not actually called do indeed get handled eventually, but they produce no effect; everything remains at the stage of cb({}).

The timeout is mostly so it doesn't keep blocking other updates

It's unfortunate, but at first glance, there are indeed some unexpected reasons on my part. Regardless, I will try to follow your advice as much as possible, as you said, at least until I actually encounter this issue.

[NGPONG]

Hey @folke, just wanted to let you know that I’m about to closeing this issue. As mentioned earlier, I’ve avoided the previously discussed issue by implementing deltas updates. If there’s anything else needed, I’ll add an implementation example here for anyone who needs it. Have a great day!

[folke]

You can keep it open for now. I'll see if there's a proper way to deal with timeouts.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.