User Snippets and file icon for carbon and microsoft C/C configurations #4373
Conversation
github-actions
bot
added
the
utilities
…etrun type removes
|
@geoffromer Can you review this latest commit? |
|
@jonmeow please review |
| @@ -2,54 2,67 @@ | |||
| "package": { | |||
| "scope": "carbon", | |||
| "prefix": "package", | |||
| "body": "package $fileNameWithoutExt", | |||
| "body": "impl library ${1:$fileNameWithoutExt}", | |||
There was a problem hiding this comment.
I think we should still have package, especially since that's the name and the prefix for the snippet; we just shouldn't provide a default. We could always have a separate library snippet for the case where the user doesn't want to specify a package.
It's probably also better to leave out impl, because every library has an API file but not every library has an impl file, so leaving it out will be the right guess slightly more often. It would be ideal if we could infer this from the filename (impl files should always have a .impl.carbon extension), but I don't know if that's feasible.
Finally, the library name should have quotes around it.
| "body": "impl library ${1:$fileNameWithoutExt}", | |
| "body": "package $1 library \"${2:$fileNameWithoutExt}\"", |
utils/vscode/dist/extension.js
Outdated
There was a problem hiding this comment.
This doesn't seem right. At least judging from this doc, the convention is that src contains the source code for the extension, and then the contents of dist are generated from the source code as part of bundling. As such, I'm not sure dist/extension.js should even be checked in to source control, but in any event we certainly shouldn't be removing src/extension.js.
There was a problem hiding this comment.
I actually think TypeScript would be much helpful and better for creating extension and later we can compile it to js and create vsix package
utils/vscode/package-lock.json
Outdated
Adds User Snippets and file icon for VSCode and C/C configuration for microsoft C/C intellisence