Using ivy--regex-ignore-order in lsp-ivy

[AndreaOrru]

Although I have ivy--regex-ignore-order set globally as my re-builder, lsp-ivy is not respecting this setting.

[failable]

It seems space separated match style does not work too.

[sebastiansturm]

sorry for letting this linger for so long, will have a look tomorrow

[sebastiansturm]

as far as I can see, dynamic collections don't take matchers into account, which makes sense as our input must be provided in a form the dynamic backend understands. Though as a user, I'd expect to be able to preselect a list of results using ivy-restrict-to-matches and then filter that using ivy's regexp matchers. Which in fact seems to be the case, but only if candidates are plain strings (abo-abo/swiper#2168); unfortunately, ours aren't. @abo-abo: do you currently have plans to add a :filter argument to ivy-read?

[failable]

@sebastiansturm

Is that mean that's a limitation of ivy? Since space-based match works in vscode while does not work in emacs.

---

Off topic though, it would be nice to have related files info shown in the candidate list like vscode.

[abo-abo]

@sebastiansturm

do you currently have plans to add a :filter argument to ivy-read?

There's already a :matcher keyword.

if candidates are plain strings (abo-abo/swiper#2168); unfortunately, ours aren't.

Could you please give me a simple LSP test case that I can play around with to make S-SPC work for lsp-ivy?

However, I think it would be better for the LSP server to do the spaces-based matching and for ivy to only display the results. Similar to how counsel-rg works.

[sebastiansturm]

@sebastiansturm

do you currently have plans to add a :filter argument to ivy-read?

There's already a :matcher keyword.

oh, indeed. Not sure how I managed to miss that when I was looking for filter yesterday; thanks for the pointer!

if candidates are plain strings (abo-abo/swiper#2168); unfortunately, ours aren't.

Could you please give me a simple LSP test case that I can play around with to make S-SPC work for lsp-ivy?

there's a very minimal example included with lsp-ivy; sample-project/create_compile_commands.rb creates a compile_commands.json file so that with clangd (or ccls) you should be able to search for symbols defined within some_other_file.cpp or some_file.cpp

However, I think it would be better for the LSP server to do the spaces-based matching and for ivy to only display the results. Similar to how counsel-rg works.

yes, given @Isolet's remark I should probably have a look at what vscode is doing.

[sebastiansturm]

@sebastiansturm

Is that mean that's a limitation of ivy? Since space-based match works in vscode while does not work in emacs.

thanks, didn't know that; from a cursory glance at their github repo (symbolsQuickAccess.ts) it seems they pass the first word to the server and then use the rest for client-side filtering. Can have a look at that the coming weekend

Off topic though, it would be nice to have related files info shown in the candidate list like vscode.

that sounds like a very useful feature too, thanks for the suggestion!

[sebastiansturm]

I opened a PR that partially addresses your request, though it does no fancy fuzzy matching, just simple string comparisons with the space-separated queries you provide. Could you check and see if that fits your needs?

[failable]

@sebastiansturm The PR works quite well for me (not the original OP's request though), except some of the file info not shown.

[sebastiansturm]

strange, could you enable lsp-log-io and post the missing candidates' uri fields please? As well as your value of (lsp-workspace-root)

[failable]

The value of (lsp-workspace-root) is

which is correct.

When I type parse args, I notice the first candidate is the parse_args in semantic_matching.py in line 200 (confirmed by RET on that candidate and the cursor jumps there), which has a [FUNC] type.

And the output of the uri part is

The only strange part to me is the "name" field, the variable parser is actually in line 201, and I can not find any line: 201 in buffer *lsp-log: mspyls:14807*, but the candidate for parse_args.parser has related file path shown as shown in the second image (The second candidate), while parse_args itself has not.

[sebastiansturm]

I doubt that's one of the offending matches - it specifies "kind": 13, so I assume it's one of the [Var ] items which seem to show up with correct file paths. Could you perhaps post all parse_args/parser items (or perhaps just those with "kind": 12?

[failable]

Here's all the logs since the server is started until I do the first lsp-ivy with parse args: log.

[sebastiansturm]

thanks! According to your log, the parse_args function specifies no containerName, and I accidentally bound the addition of pathstr to container-name? being defined. Will push a fix shortly

[sebastiansturm]

I force-pushed the change, please have a look

[failable]

@sebastiansturm Works like a charm. Thanks and sorry for hijacking the thread.

[sebastiansturm]

thanks for your help! Will merge this then, but leave the issue open as the original request remains unaddressed

[nbfalcon]

This might be solved by #24 eventually, since then we will be passing strings to ivy-read.