-FLAG:"PATH" Style Completion Not Working

[CampinCarl]

First, huge thanks to the developers for keeping this project alive; it's awesome!

I'm trying to get -flag:"path" style completion working, which works in v0.4.9 when a double quote is present. Here's a use case example with Saxonica's XSLT utility, ref: Saxon Documentation - Running XSLT from the Command Line

C:\>Transform.exe -xsl:"foo.xsl" -s:"source.xml"

1. Command completion works fine, i.e., transf + [TAB] = Transform.exe
2. Flag completion works (via Lua), i.e., -xs + [TAB] = -xsl:
3. Path completion does not work, i.e., -xsl:" or -xsl:"foo + [TAB] = -xsl:"/-xsl:"foo (no path completion)

I think it might be possible to replicate this behavior in Lua? Conceptually, I'm looking for a way to treat the colon as a separator between the -xsl flag and the foo.xsl argument, similar to the Linking Parsers example. The clink.filematches function looks suitable for this purpose, but I don't know how to solve the colon issue.

Any advice from the devs/community would be greatly appreciated.

[chrisant996]

Makes sense, thanks for the description and context information.

I'll take a look. Yes, a generator can handle that manually (see getwordbreakinfo, or something like that; I forget the exact name offhand). But this behavior should be built in so that argmatchers get it for free. Plus, it presents an interesting edge case for input colorization.

[CampinCarl]

You're welcome and thanks for taking a look at this. I'll play around with :getwordbreakinfo(), though admittedly I'm not an expert with Lua (should be fun though!).

[chrisant996]

This is a very good find, thank you!

complete indeed doesn't work at all in that case. However, menu-complete is sort of able to insert matches, but can't handle more than one path component (e.g. -x:"foo but not -s:"foo\bar).

The problem is a nuanced mismatch between how Readline and Clink (v1.0 and higher) think about match expansion. Clink breaks the line into words, and uses completion to extend words. Readline backtracks from the current cursor point to find a point to start matching; one point is an unclosed quote, another is a word break, and so on.

Readline sees foo -x:" as starting a match completion after the unclosed ".
Clink sees foo -x:" as two words foo and -x:", and tries to complete the word -x:".

The Clink rewrite wasn't designed to handle this case, so I'll need to do some minor surgery on the design.

Clink needs to be able to see it as three words foo, -x:, and ". That's important for completion, for linked argmatchers so subsequent words are interpreted correctly, and for input colorization so -x: gets colored as a flag even though there isn't a space after it.

But there's more to it:

• If there's a linked argmatcher for a flag ending in : or =, then the next part should be considered a separate word so the argmatcher can supply matches for it.
• If there's not a linked argmatcher, then the next part should not be considered a separate word. Except that input colorization should consider it a separate word. Tricksy...

This will require some thought to make sure it's all handled well, without making things complicated for lua scripts.

[chrisant996]

Clink 0.4.9 does not work correctly in this case, by the way. It interprets the quoted string as a separate word as though it were not connected to the -flag: string.

For example:

• net -flag:"Tab lists arg1 matches as possible completions: accounts, computer, config, etc.
• net -flag:"config" Tab lists arg2 matches for config as possible completions: server, workstation.
• git -flag:"checkout" Tab lists files plus branch names as though git checkout had been used.

[chrisant996]

Here's what I think is needed:

1. Make the -flag:"text" case not be handled by argmatchers, and simply default to file completions.
2. Make the -flag: part be colored as a Flag, and make the "text" part be colored as Other.
3. Explore adding some lua syntax to supply a match generator for a flag with no space after it. Maybe the + operator could be taken over, e.g. { "-flag:" + some_function_name }.
4. Provide some way for a custom classifier to apply a classification to any region in the input line, not just to a pre-parsed word.
5. Provide some way for a custom classifier to apply any arbitrary color to a pre-parsed word or to any region in the input line.

I've opened 3 new issues to track those:
#61 tracks points 1 and 3.
#62 tracks point 2.
#63 tracks points 4 and 5.

Thanks again @CampinCarl for noticing and reporting this!

FWIW, point 3 is "nice to have", but is not required -- I think it shouldn't be very expensive to support, but I can't promise anything just yet. The reason it isn't strictly required is that custom generators can be written to handle any arbitrarily complex syntax in an input line. For example, a custom generator handles environment variable completions embedded within words, and the entire argmatcher system is itself just a built-in custom generator.

[CampinCarl]

Thanks Chris! Interesting point on v0.4.9. Sounds like it "worked" for what I needed but wasn't actually working as intended. I'll keep an eye on the new issues you've opened.

[CampinCarl]

Checking in to say the new build works great for this use case. Thanks!

[chrisant996]

Thanks for confirming!