SemanticClassificationType should not be internal

[cloudRoutine]

In service.fsi SemanticClassificationType is marked internal yet

member GetSemanticClassification : unit -> (range * SemanticClassificationType)[]

is public and uses it as one of its return types, which makes this member unusable from FSAC and kills the colorization functionality.

[vasily-kirichenko]

Yes, it should be fixed. FSAC has never had colorization functionality though.

[cloudRoutine]

we don't use it for Ionide, but it has been there. I don't know if the other editor plugins make use of it

member __.GetExtraColorizations = checkResults.GetExtraColorizationsAlternate()

there are a bunch of integration tests for them too

[7sharp9]

I believe they were turned off for performance reasons in VS.

…

On 11 February 2017 at 18:46, Jared Hester ***@***.***> wrote: we don't use it for Ionide, but it has been there. I don't know if the other editor plugins make use of it member __.GetExtraColorizations = checkResults. GetExtraColorizationsAlternate() <https://github.com/fsharp/FsAutoComplete/blob/master/src/FsAutoComplete.Core/CompilerServiceInterface.fs#L147> there are a bunch of integration tests for them too <https://github.com/fsharp/FsAutoComplete/tree/master/test/FsAutoComplete.IntegrationTests/Colorizations> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#696 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAj7yg_F3cW1SMDDu5ZMSLbPhydRoYCvks5rbgIhgaJpZM4L-NEe> .

[vasily-kirichenko]

The old method returned classification for computation expression names and CE custom operations usages only. It was used in VFT 2015, but not in VFPT ('coz why if VFT used it anyway and we could not switch it off). VFPT has richer colorization code, but I don't like to port it to VFT, VFT uses a bit lower level and 10x simpler approach (which is exposed as this new GetSemanticClassification method). I think it should be used by other editors (and FSharp.Formatting) instead of porting VFPT code.

[forki]

Comment? Why not remove it completely?

[Krzysztof-Cieslak]

@dsyme, can we get NuGet release of this fix as soon as possible? :)

[dsyme]

How about grabbing it off the AppVeyor build?

[forki]

They want to use it in ionide and fsac. I think that should be a blessed version then. Am 13.02.2017 16:59 schrieb "Don Syme" <[email protected]>:

…

How about grabbing it off the AppVeyor build? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#696 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNCX7ruQ6kTdFnYpaMyhBtVBdfKE0ks5rcH30gaJpZM4L-NEe> .

[forki]

Is this already merged back to Visualfsharp?

[vasily-kirichenko]

@forki it's not needed there, but I think no.

[forki]

not needed - but we should keep it consistent. otherwise things will conflict and merge errors will happen. and doom.

so: dotnet/fsharp#2440