Initial delay in the new global search experience

[xJonathanLEI]

Summary

Same as #11205, filing as bug report as this used to work.

There seems to be an initial delay in the new picker-based global search experience. Once a pattern is entered, it takes a short while before the actual searching begins. I haven't looked at the code but I feel like this is intended to be a feature?

One important use case of the global search has been broken by this behavior. Often I find myself knowing for sure a certain string pattern exists and only ever exists once in the entire project. All I want to do is to very quickly get to that line in that file to start working on it. What I used to do is a quick <space> / [paste] <enter>. I'd not wait before pressing <enter> as I know for sure there's one and only one occurrence inside the whole project. But now this workflow is broken thanks to the delay, as the actual search only starts after the input delay, before which I've already pressed <enter>, failing to open any file.

I feel like this is common enough use case that it should not be broken. For example, when running tests and some of them fail, it's common to copy the test case name and search for that.

Even in cases where more than 1 occurrence is expected, the delay makes searching experience much worse than before.

Yes, I know that global search has turned async a long time ago so there's a chance that the algo just isn't discovering the file quick enough. But not, doing this one a folder containing like 5 files and you'd still run into the issue.

Reproduction Steps

Copy something that exists in your project into your clipboard, and quickly perform the <space> / [paste] <enter> combo. You'd expect a file to be opened but none actually does.

Helix log

N/A

Platform

Any really

Terminal Emulator

Any really

Installation Method

Any really

Helix Version

helix 24.7 (b0cf86d)

[kirawi]

See #9647 (comment)

[xJonathanLEI]

@kirawi Thanks for the pointer.

I'm aware this breaks muscle memory but I'd rather have a better interface even if it means people have to retrain their muscle memory.

Typically when it's just about "muscle memory" I would remind myself that the new way could be better. But in this case, the same task is indeed taking longer and therefore the new impl is objectively inferior, at least for certain use cases. The cognitive overhead is also higher as the user would now need to monitor the list to wait for it to be populated, and only then press the Enter key, before returning to what they were originally planning to do. That extra overhead is... undesirable at best.

Can we at least get the old non-interactive version back so we have two ways to do global searching. Personally I feel like these are 2 different use cases:

1. The user knows exactly what they want to search for. There's no interactivity needed. Actually, they might benefit more from the fact that you can browse through the search history as in the old searching command. This is the case for the good-old non-interactive search.

2. The user doesn't know the exact pattern and they want to tweak it as they go, based on the live result. This is a perfect use case for the new interactive search. In this case, making the debounce configurable might be an option.

Tagging @the-mikedavis.

WDYT?

[the-mikedavis]

We could skip the debounce when inserting from a register or pasting. That would remove the delay both when you accept the suggestion from the history register and in your workflow.

[the-mikedavis]

I looked back at the 24.07 release and I thought we blocked the UI waiting for the old global search but that isn't the case, so the Enter keypress can't quite be queued up. I assume that in your workflow the search is fast enough that it finds your pattern before the Enter is processed. With #11211 the behavior should be roughly the same as long as you're pasting or using the suggestion from the / register

[lemontheme]

Replying to your comment here, @the-mikedavis, just to keep the discussion in one place.

The cognitive overhead is also higher as the user would now need to monitor the list to wait for it to be populated, and only then press the Enter key, before returning to what they were originally planning to do.

100% agree.

Just like @xJonathanLEI, I rely on global search because it is (or, rather, was) the fastest way to switch to something that you know for sure exists in one or just a few files.

For cases where the query is copy-pasted, I think skipping the debounce on the initial query makes sense. This already covers many of my needs, so that's definitely a positive!

But sometimes it's faster to just type the query out manually. I know when the query is complete, so there's no real need for intermediate searches. If I've got this right, the solution proposed is to make the debounce interval configurable so as to allow one to find the right balance between getting results fast and not spending resources on unnecessary search operations? If so, I have my doubts about this delivering the same feeling of immediacy as before – at least, not without sacrificing computational efficiency.

I think the new pickers interface is fantastic. And I can understand that this change to how global search is triggered is to bring it more in line with how other finders are interacted with. Indeed, global search was always the odd-one-out in this regard.

With some obvious bias, though, I'd argue that global search merits being a bit different. After all, the / key evokes type query -> <enter> -> scroll results, since that's how it works in Vim, Tmux, Zellij, Less, Man, ... – even in Helix! I always liked it that cmd+/ maintained this analogy.

Apart from keeping things consistent, is there any reason why the first global search query can't be triggered manually, after which the new interactive picker opens?

[the-mikedavis]

I'd mostly be worried about setting the debounce so low that you can't type two characters at normal speed without starting a search between them. Changing the query while a search is ongoing cancels the search so you aren't spamming full searches for every character entered with a low debounce. I suspect we can lower it to the point where it feels fairly immediate.

The debounce constant for global_search is set here in milliseconds:

helix/helix-term/src/commands.rs

Line 2442 in 748a9cf

.with_dynamic_query(get_files, Some(275));

If you're building from source it'd be great if you could try tuning that constant to see if there's a value that feels right. We set the default debounce as low as 100ms for the LSP workspace_symbol_picker although that strikes me as a little low for global search.

is there any reason why the first global search query can't be triggered manually, after which the new interactive picker opens?

This seems like a clunky UX to me: you need to enter the query first in a prompt at the bottom of the screen and then your focus moves up to the picker's prompt near the top

[RoloEdits]

Seems like it should be pretty easy to make this a config option as well, what are thoughts on adding this to [editor]?

[archseer]

It should just use the existing idle-timeout config. That's currently used for completion but the point of it was to set it to a value high enough to trigger only when you stop typing. This highly depends on your average typing speed

[xJonathanLEI]

I agree that "instant search on paste" already covers most of the use case, though it leaves out the case where I use a "WIP marker" like damn to mark lines of code I'm debugging lol. Such markers are extremely quick to type out than average code so it will always go under any idle threshold. But that's rather minor and I can live with it.

In cases that do get covered though, the new way is actually faster than the old prompt way by saving one <enter>. In the old prompt-based search, you need one <enter> to open the picker and another to pick the file; the new one saves you the pick-triggering key press.

[aukeroorda]

Might it be useful to reintroduce the first <enter>?
This will then be a consistent, reliable way to start the first search, regardless of typing speed. After this, the search can be refined dynamically, and the debounce timeout can be used, i.e. from there on out, the enter keypress will open the selected item.

I'm not sure how this experience will be, but I think it allows for both fast, deterministic (I know what I'm looking for) searches as well as more browsing-like using the dynamic approach.

Anyhow, I appreciate how this is discussed, thanks for everyone's contributions!