search

ionide / ionide-vscode-fsharp

VS Code plugin for F# development
http://ionide.io
MIT License
850 stars 276 forks source link

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

Closed Tangent-90 closed 8 months ago

Tangent-90 commented 8 months ago

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 (fsharp/FsAutoComplete#1178) to package.json
  2. fix: PipelineHint display wrong with localized type param output (wrong display examples like #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

baronfel commented 8 months ago

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.

Tangent-90 commented 8 months ago

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.

Tangent-90 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 :)

Tangent-90 commented 8 months ago

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 commented 8 months ago

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.