Adds setting for FullNameExternalAutocomplete, Fix PipelineHint localization, Fix sending lines to fsi

[ijklam]

WHAT

🤖 Generated by Copilot at 53f4abb

This pull request adds a new option for customizing external autocomplete, a feature for sending the current line to F# interactive, and a bug fix for the pipeline hints type signatures. It affects the files release/package.json, src/Components/Fsi.fs, and src/Components/LineLens/PipelineHints.fs.

🤖 Generated by Copilot at 53f4abb

If you want to use F# in VS Code
You might like this pull request's load
It fixes getSignature
Adds fullNameExternalAutocomplete
And lets you send lines to Fsi mode

🐛🛠️🚀

WHY

1. add: new FSAC config fullNameExternalAutocomplete (Better Completion for ExternalAutocomplete functions FsAutoComplete#1178) to package.json
2. fix: PipelineHint display wrong with localized type param output (wrong display examples like How to get localisation disabled? #1653), now it will correctly display hints without cutting too much to the type name, adding extra "1" or word "is" (like "是" in Chinese, "は" in Japanese).
3. improve: use correct line number when sending lines to fsi. This change makes the line numbers consistent in FSI and the editor, may making scripts easier to debug.

HOW

🤖 Generated by Copilot at 53f4abb

• Add a new configuration option for external autocomplete (link)
• Support sending the current line to F# interactive terminal (link, link, link)
• Fix type signature extraction for pipeline hints (link)
• Add a newline at the end of release/package.json (link)

[baronfel]

Hi, thanks for this! The fixes for 1. and 3. make sense to me - can you clarify on what the problem for 2. was? I'm having a hard time understanding what the minimal version of the problem is.

[ijklam]

Hi, thanks for this! The fixes for 1. and 3. make sense to me - can you clarify on what the problem for 2. was? I'm having a hard time understanding what the minimal version of the problem is.

When displaying pipeline hints, it will first find the type parameters of operator (|>), and then extract type names. The problem is that the original way to extract names is based on English (as it will first find the word "is"), and will reduced wrong output when compiler doesn't give an English text.

For example, in this code snippet

1
|> (+) 2

F# compiler will give " 'T1 is int " and " 'U is int " under English environment, and will extract type names correctly to "int".
But in a Chinese environment, the results of compiler will be " 'T1 是 int " and " 'U 是 int ", both doesn't contains "is", so will display hints like "1 是 int " and " 是 int ". And when the type name contains "is", it will take the word after the "is" as the output.

[ijklam]

As all the localized "is" listed in text of F# compiler is a single word (like this, and type parameters text is all like "'T is something", so we can use a regex to extract the type name out.

[baronfel]

Ok, that makes sense. It is fair to say that a better FSAC endpoint targeted for this use case would make this task easier/less variable for non-English locales?

[baronfel]

Also, unrelated to this PR - would you suggest that Ionide itself support localizations for strings that we have or emit? Like the settings descriptions, etc? I've recently set up localization for another VSCode extension and it's on my mind.

[baronfel]

Note that we'll need to publish and update FSAC before this setting will have any effect, but we can do that today so that we can push this out :)

[ijklam]

Ok, that makes sense. It is fair to say that a better FSAC endpoint targeted for this use case would make this task easier/less variable for non-English locales?

What does this exactly mean?

Also, unrelated to this PR - would you suggest that Ionide itself support localizations for strings that we have or emit? Like the settings descriptions, etc? I've recently set up localization for another VSCode extension and it's on my mind.

if it's not difficult to achieve, then it is a good idea.

[baronfel]

Ok, that makes sense. It is fair to say that a better FSAC endpoint targeted for this use case would make this task easier/less variable for non-English locales?

What does this exactly mean?

All I mean here is that I think it would be useful for FSAC to have an API specifically for powering pipeline hints (possibly using the same infrastructure as other inlay hints?) and let FSAC use a more structured form of the data instead of the string manipulation that currently happens in Ionide.