Strikeout CompletionItems (and Symbols?) that are deprecated

[rcjsuen]

Ctrl+Space is nice and all but when you are new to a library you just see a list of functions and you won't realize that some of them are deprecated. Would it be possible to add a strikeout line via the line-through text-decoration or some kind of icon overlay to indicate that something is deprecated?

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Add extension deprecation and redirection (#4772)

[octref]

@jrieken I'm interested in this too, for deprecated html/css properties.

[ivanvoznyakovsky]

it'd also be great to strikeout deprecated props/methods in the editor itself like webstorm does it. ie

[KamasamaK]

@ivanvoznyakovsky The only way to currently set whether the property or method is deprecated would be to use invalid.deprecated in the TM syntax. I have proposed the capability of doing this through the API in #56694

[jcrben]

Raised a couple times previously:

• Feature request: highlight deprecated functions (JS/TS) #31159
• @deprecated support in TypeScript #10316 - recommends using extension with textDecoration API @deprecated support in TypeScript #10316 (comment)

At least we currently should see when using trying to use an @deprecated function (#26541)

[KamasamaK]

@jcrben Those are issues for language support. This issue is more general, and I think this is an issue to support the deprecated property on the completion and symbol items in the LSP spec with a visual change. Perhaps also to add those properties to the native API.

When this is done, I would expect more language support would follow. It's possible that some language servers already do set that property but you don't know since VS Code ignores it.

Specifically on those issues you posted, I don't agree with the notion that it should be done in a separate extension or that it should use the decorations API. Deprecation is a standard practice in software development, and in the case of JavaScript/TypeScript there is JSDoc to determine this, which is already being parsed and used for other doc tags.

[Tyler-Murphy]

I'd like something similar to this. I'd like to be able to prevent deprecated things from showing up in the list of suggestions at all.

[jrieken]

@kamranayub's work on this is sitting here: https://github.com/microsoft/vscode/tree/joh/completionsDeprecated.

[fbricon]

Testing on vscode-java with initial deprecated support in jdt.ls, in Insiders build ada79d7 :

I'll keep testing with newer builds next week.

cc @akaroml

[rcjsuen]

What a time to be alive...

[jrieken]

Closing. We have the UX for outline, workspace symbols, and completions. The API is proposed and will be finalised in #23927

[fbricon]

@jrieken I tested today's insiders build (185308c 2019-08-26T09:43:06.818Z) and I no longer see the completion/symbols striked through O_o. Is there something I need to enable in my extension now?

[jrieken]

What version of the proposed API did you code this against?

[fbricon]

latest LSP release. Which adds the deprecated property to completion items, workspace and document symbols. completion items worked last week, as per my screenshot.
I tried to add vscode.proposed.d.ts by calling npx vscode-dts dev. But I'm not sure where the file is supposed to go. In my project root? my project source folder? Either way I don't get the strikethroughs.

[fbricon]

enableProposedApi is set to true too. Wasn't necessary last week.

[jrieken]

latest LSP release.

I don't think that's weird up (@dbaeumer) yet. It might have worked by accident because the first proposal used the same names. The proposed API (CompletionItem.tags, SymbolInformation#tags) is described here: #23927

[fbricon]

do you plan to get VS Code support the deprecated properties of the current LSP version?
On the Java side, those new tags are not yet supported by the LSP4J bindings, so it'll take us more time to have that deprecated support that way.

[jrieken]

LSP and vscode.d.ts are two separate things. The LSP-vscode-client fulfils the vscode.d.ts-contract, e.g it will map the deprecated-field that LSP defines onto the completion item tag that vscode.d.ts defines. The sequence is that we finalise the API next milestone, that LSP adopts the new API, and that things then come together.

Since you are on the LSP side and since to my knowledge deprecation is already supported there (but not yet wired up), there is nothing you have to do

[fbricon]

ok, can you please let me know when this is wired up in vscode then?

[danielhofinger]

Hi Fred, can you please remove me from your “subscribed”-list? Thanks. Best, Daniel Daniel Hofinger Founder & Managing Director, Hofinger Ventures UG A Mörfelder Landstraße 6-8, 60598 Frankfurt am Main M +49 177 8431872 E [email protected] W www.hofinger.xyz Hofinger Ventures UG (haftungsbeschränkt), Luisenstraße 34, 60316 Frankfurt am Main; Geschäftsführer: Daniel Hofinger; Amtsgericht Frankfurt am Main; HRB 108730; USt.-IdNr.: DE312772958; Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, Veröffentlichen sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient (or have received this e-mail in error), please notify the sender and delete this message. Any unauthorized publishing or copying of this message or unauthorized distribution of the information contained in this e-mail is strictly prohibited.

…

On 26. Aug 2019, 17:41 +0200, Fred Bricon ***@***.***>, wrote: ok, can you please let me know when this is wired up in vscode then? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[fbricon]

I didn't add you. But you can unsubscribe from notifications from this issue by clicking on the "Unsubscribe" button here.

[KamasamaK]

@fbricon This is already working in VS Code with the proposed API. What you're likely waiting for is support in microsoft/vscode-languageserver-node.

[akaroml]

I didn't add you. But you can unsubscribe from notifications from this issue by clicking on the "Unsubscribe" button here.

Hey Fred, I think the enableProposedApi is no longer needed because the changes are already in the latest release of the vscode-languageclient v5.3.0-next.9. Could you try to upgrade the client to see whether it works? Thanks.

[dbaeumer]

@jrieken is correct. It is not wired up yet. I only wire up new API if it is at least released in a stable build. I don't make a dependency on Insider in LSP libs (I once did and it confused a lot of users).

However you can implement this yourself using a custom middleware if you really need to do so.

[danielhofinger]

Hi Dirk, please remove me from CC, thanks. Best, Daniel Daniel Hofinger Founder & Managing Director, Hofinger Ventures UG A Mörfelder Landstraße 6-8, 60598 Frankfurt am Main M +49 177 8431872 E [email protected] W www.hofinger.xyz Hofinger Ventures UG (haftungsbeschränkt), Luisenstraße 34, 60316 Frankfurt am Main; Geschäftsführer: Daniel Hofinger; Amtsgericht Frankfurt am Main; HRB 108730; USt.-IdNr.: DE312772958; Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, Veröffentlichen sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. The information contained in this message is confidential or protected by law. If you are not the intended recipient (or have received this e-mail in error), please notify the sender and delete this message. Any unauthorized publishing or copying of this message or unauthorized distribution of the information contained in this e-mail is strictly prohibited.

…

On 27. Aug 2019, 09:09 +0200, Dirk Bäumer ***@***.***>, wrote: @jrieken is correct. It is not wired up yet. I only wire up new API if it is at least released in a stable build. I don't make a dependency on Insider in LSP libs (I once did and it confused a lot of users). However you can implement this yourself using a custom middleware if you really need to do so. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[dbaeumer]

@danielhofinger you need to unsubscribe yourself from the issue using the GitHub UI.

[danielhofinger]

Alright, thanks! @dbaeumer

[fbricon]

@jrieken is correct. It is not wired up yet. I only wire up new API if it is at least released in a stable build. I don't make a dependency on Insider in LSP libs (I once did and it confused a lot of users).

However you can implement this yourself using a custom middleware if you really need to do so.

I don't think I'm gonna start messing with custom middleware code (don't even know what to do). So I'll just wait for you to wire things up in the insiders build at least

[Tyler-Murphy]

#77239 was marked as a duplicate of this issue and closed.

@jrieken said:

I'd say this is a dupe of #50972 and it would be us adding some API flag and then allows users to configure how the suggest UX is handling that flag

Does the closure of this issue address #77239? Should #77239 be reopened?