smooth one-shot finder

[dkuettel]

trafficstars

I'm trying to improve responsiveness and smoothness of the user experience if you have slow one-shot finders. Slow because the command you run is slow, not slow because the actual lua code is heavy.

If you use a finder like this

            finder = finders.new_oneshot_job({ "test-telescope" }, {
                entry_maker = function(line)
                    return {
                        value = line,
                        display = line,
                        ordinal = line,
                        path = "./some.py",
                        lnum = 12,
                    }
                end,
            })

and you have this script in your path

#!/bin/zsh
set -eu -o pipefail

for i in $(seq 100); do
    sleep 0.15s
    if [[ $(( $i % 10 )) == 0 ]]; then
        echo $i signal
    else
        echo $i noise
    fi
done

then, on current master, you'll notice a bumpy ride:

• If you just wait, and dont type, the status counter is counting up, but you dont see any entries in the results window. Unless you have the picker in dropdown mode.
• If you start typing a search expression, results dont filter until after the command has finished. There is no incremental search results.
• The status counter updates only when there is a result that's filtered in, it doesnt update when there is a new entry that is not shown.
• Even after the command has actually finished, and you change the search expression, the result buffer updates with a mix of new and old results and only eventually shows a clean list. However that is only really visible if the finder lua code is slow, not the command. After the command has finished, the one-shot finder has all entries cached and it's probably reloaded too fast to notice unless you make it slow on purpose.

There is still a pretty big TODO comment in async_oneshot_finder.lua where I'm still a bit lost. Overall I'm not very robust on plenary, libuv, and the whole async stuff. But I noticed that sometimes process_results(...) fails because it tries inside to call vim.api functions and that is only allowed (?) when we are on the main event-loop. Originally async.util.scheduler() was only called every 1000 entries or so. But if I do that I occasionally get the problem with vim.api calls. I dont quite understand what the scheduler() is doing.

[Conni2461]

This problems is a problem with sorting_strategy="descending" (which is the default strategy). It works find with sorting_strategy="ascending"

I dont wanna comment on this prior to #1491 (just tested it with that PR and it also seems to be fixed using that branch). This PR completely changes the rendering.

Thanks for the PR thought :)

CC @tjdevries

[dkuettel]

This problems is a problem with sorting_strategy="descending" (which is the default strategy). It works find with sorting_strategy="ascending"

I dont wanna comment on this prior to #1491 (just tested it with that PR and it also seems to be fixed using that branch). This PR completely changes the rendering.

Thanks for the PR thought :)

CC @tjdevries

I've seen #1491 :) but I dont know how soon it will be on master.

Indeed the small fix I made is because of ascending vs descending. And this fix might then soon be obsolete. And admittedly very ad-hoc and messy.

However, the changes on async_oneshot_finder.lua, where I need some feedback on, will probably still make sense, independent of the "rendering engine". Unless #1491 will also change the interface between the picker and the finder?

[dkuettel]

Sadly, this is still an issue :) I tried it with b79cd6c and it doesnt handle slowly produced results gracefully. Someone mentioned https://github.com/nvim-telescope/telescope.nvim/pull/1491 might fix this instead of my change. Is that still the case, should we wait for that? However, my change is orthogonal to the rendering approach, isn't it? It changes how we collect results, not how we render them.