Skip to content

Bash: Add snippets for VS Code #664

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 23 commits into from Jan 10, 2023
Merged

Bash: Add snippets for VS Code #664

merged 23 commits into from Jan 10, 2023

Conversation

EmilyGraceSeville7cf
Copy link
Contributor

@EmilyGraceSeville7cf EmilyGraceSeville7cf commented Jan 7, 2023

Add snippets for:

  • language constructs
  • builtins
  • expansions
  • devices

Motivation: have standardized and easy memorable snippets.

@EmilyGraceSeville7cf
Copy link
Contributor Author

I guess I can do the same job for other supported editors by this extension. :)

@skovhus
Copy link
Collaborator

skovhus commented Jan 7, 2023

Thanks for the contribution!

I guess I can do the same job for other supported editors by this extension. :)

Yes, if we move this to the server (instead of part of the vscode extension as done here), then all editors will get these snippets available. I believe that is the way to go if we support snippets.

I’m curious to know how many would prefer having snippets available. I assume we need a way to disable them or potentially override them. As the server is used by a lot of people, we need to think about the reception of this feature.

Example of other language servers returning snippets: https://github.com/iamcco/vim-language-server/blob/30f442dfa0ff8436eceeb2a306d1e8fd17bbdc6b/src/server/snippets.ts

@EmilyGraceSeville7cf
Copy link
Contributor Author

@skovhus, it's possible to disable them now AFAIK.

@EmilyGraceSeville7cf
Copy link
Contributor Author

Is it possible to move snippets to server a little bit later but now accept these ones? I am not JS/TS developer that's why I am asking for it.

@skovhus
Copy link
Collaborator

skovhus commented Jan 8, 2023

Is it possible to move snippets to server a little bit later but now accept these ones? I am not JS/TS developer that's why I am asking for it.

That’s a nice and lean approach. Then we might get some feedback before rolling this out to all clients.

Let me know once you are satisfied with these. I’m not a big snippet developer myself, so I would need to spend some time playing around with these. Maybe there are some standard bash snippets that we can get inspiration from?

"{${1:from}..${2:to}}"
]
},
"echo": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how much value very basic snippets like echo and source provides.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to save some keystrokes and quote argument automatically. :)

"description": "[cd]",
"prefix": "cd",
"body": [
"cd \"${1:path/to/directory}\" || echo \"${2:error_message}\" >&2"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems rather non-generic.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do u mean? Can you tell me what you expect to see? I've added || as cd potentially can fail.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For snippets to be useful I believe they should be fairly generic and applicable for most users. A good example is the test snippet that is a very generic. For cd we assume that the user wants to handle error case like this and swallow the error (exit code would be 0 after running this).

I would like us to remove the snippet for cd for now.

"let ${1:argument}"
]
},
"test": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test seems really useful with all the different options here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

=~ has been added.

@skovhus skovhus mentioned this pull request Jan 9, 2023
EmilySeville7cfg added 2 commits January 10, 2023 00:05
Copy link
Collaborator

@skovhus skovhus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a really good start! Thanks for your work. I've added a few suggestions. I believe we can release this soon. 👏

@@ -0,0 +1,16 @@
# Snippet naming convention
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice with this documentation. Once the snippets are in TypeScript, then we should change this markdown file to some unit tests to ensure that this is enforced.

"[[ ${1:argument1} ${2|-ef,-nt,-ot,==,=,!=,=~,<,>,-eq,-ne,-lt,-le,-gt,-ge|} ${3:argument2} ]]"
]
},
"device": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest we get rid of the device. They content here are all standard streams and not really devices, and I'm not convinced anyone would find them by typing de.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've renamed snippet to stream.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also not convinced anyone would find them by typing stream, so I would just get rid of it. But no strong opinion here. :)

Copy link
Contributor Author

@EmilyGraceSeville7cf EmilyGraceSeville7cf Jan 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But we don't need to type stream we need to type dev now as it's one of the prefixes. :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah awesome! 👏

"description": "[cd]",
"prefix": "cd",
"body": [
"cd \"${1:path/to/directory}\" || echo \"${2:error_message}\" >&2"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For snippets to be useful I believe they should be fairly generic and applicable for most users. A good example is the test snippet that is a very generic. For cd we assume that the user wants to handle error case like this and swallow the error (exit code would be 0 after running this).

I would like us to remove the snippet for cd for now.

@EmilyGraceSeville7cf
Copy link
Contributor Author

EmilyGraceSeville7cf commented Jan 10, 2023

I would like us to remove the snippet for cd for now.

Can I ask what best shell scripting practices to stick with to form expectations of what user might want to type? Can we assume that user don't want to include error handling for cd-like commands by default?

I've removed error message printing from this snippet now.

@skovhus
Copy link
Collaborator

skovhus commented Jan 10, 2023

Can I ask what best shell scripting practices to stick with to form expectations of what user might want to type? Can we assume that user don't want to include error handling for cd-like commands by default?

As there isn't one standard way of doing it and the command is so trivial to type, I don't see that much value in keeping it.

@skovhus skovhus enabled auto-merge January 10, 2023 13:45
@skovhus skovhus merged commit d9dc4cd into bash-lsp:main Jan 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants