Disable method snippets in arguments

[svipas]

As title says, I can't find a setting for this.

What I mean is that I don't like if I type Object() I get these suggestions:

I see that it is related to method snippets setting, but I don't want to disable whole method snippets feature only this one.

[zardoy]

Oh, I see you have "tsEssentialPlugins.methodSnippetsInsertText": "all", which is really cool! To be honest, I didn't really test this feature, so I glad it works!

And yes, this is easy to fix, I think I'm going to introduce a setting methodSnippets.ambiguousSuggestions: "always-expand" | "always-ignore" | "expand-on-second-accept" (default, current behavior), so when methodSnippetsInsertText is in use, it wont add signature to these ambiguous suggestions (and only when you set always-expand it will)

[svipas]

Thank you very much 🙏

Yeah I love "tsEssentialPlugins.methodSnippetsInsertText": "all" it should be built-in VS Code feature for sure, it's weird that they don't include it even though I think VS Code & TS knows all that info upfront and it shouldn't cost much?

It takes time to show suggest widget if I just trigger it without any character, but when I'm typing something it works almost as fast as with that setting disabled. But benefit I'm getting is really huge, because I could see all arguments at the glance 👁️

[zardoy]

it's weird that they don't include it even though I think VS Code & TS knows all that info upfront and it shouldn't cost much?

First of all it just simply takes some time to iterate over long-requested features. For example jsx linked editing was also requested a long time ago, but was just added in latest release. Currenly, this feature is not on roadmap.

Secondly, like you mentioned, this feature has some performance issues. That's why I currently don't use it myself actually. The reason it's slow is because it needs to fully resolve the type of every completion (vscode usually does it only when you select specific completion). Actually I have another feature tsEssentialPlugins.experiments.excludeNonJsxCompletions that I use on a daily basis and IMO super useful. It also resolves type of every completion to be clear wether its JSX component and can be used here. However, this feature utilizes caching for external completions, resulting in faster performance. Here, I think we also need to cache results of completions that are outside of project, such as those in node_modules or lib.dom.

I'll also definitely try to setup script for performance test based on real projects.

[svipas]

I checked in WebStorm so seems like they support this out of the box. Not sure how they solved perf issues though. Good idea to cache those paths, but what if I add new package or update existing one, do you need to watch folder to update the cache, this sounds like a little bit overkill? I'm just curious if there's some proper way to fix it instead of introducing other possible performance/memory issues. I really like this feature and I will use it even though perf isn't the best one.

[zardoy]

Good idea to cache those paths, but what if I add new package or update existing one

This is actually very good question, I was thinking about it at some point. I'm really not sure of watching whole node_modules, but I have another extension that proved that watching lock files is a simple solution for that.

[svipas]

Very nice idea, watching lock files shouldn't be expensive. This way you know if you should recompute cache of node_modules. Also, I guess it's worth to benchmark before implementing proper cache solution to see by how fast it could get with cache, maybe it isn't worth additional effort.

[zardoy]

I checked in WebStorm so seems like they support this out of the box.

Idk, as I remember last time I checked it didn't work for some auto-import completions, as well as completions from @types/node. But I definitely remember they have completely custom logic for completions written in Java, it greatly caches all type information. By the way, thats why webstorm have completions for regex flags e.g. /foo/g|, but TypeScript never had them.

[zardoy]

Very nice idea, watching lock files shouldn't be expensive

Yes, but AFAIR the reason why TypeScript doesn't do it is because you can disable generating lockfiles like npm i --no-package-lock

[svipas]

Very nice idea, watching lock files shouldn't be expensive

Yes, but AFAIR the reason why TypeScript doesn't do it is because you can disable generating lockfiles like npm i --no-package-lock

In that case if caching adds benefit of making completions to appear faster it still worth to do it by checking lock files, but skip caching if lock file wasn't found.

[zardoy]

By the way, I'm thinking of renaming this setting, can you suggest a better name for this?

[svipas]

You mean renaming methodSnippetsInsertText or ambiguousSuggestions?

[zardoy]

methodSnippetsInsertText, because I already have methodSnippets.insertText XD

[zardoy]

Hey, I can actually see that Ambiguous Suggestions were never enabled for methodSnippetsInsertText, so I don't think I'm going to add a setting to enable them. Instead, I think you want this https://github.com/zardoy/typescript-vscode-plugins/issues/114#issuecomment-1465739883 . I can add tsEssentialPlugins.disableMethodSnippets.functionArguments and tsEssentialPlugins.disableMethodSnippets.assigning

[zardoy]

Also you can bind and use tsEssentialPlugins.insertNameOfCompletion to just insert name of the completion e.g. isObject. For example:

{
    "key": "shift+enter",
    "when": "suggestWidgetVisible && suggestWidgetHasFocusedSuggestion && editorLangId != vue",
    "command": "tsEssentialPlugins.insertNameOfCompletion"
  },