Hugo snippets in non hugo files

[maciejcieslik]

Snippets shouldn't work in any html file but only in hugo project. Now it is unusable because in other project it get in other snippets' way - for example comment snippets - in html should be {{/**/}}

[budparr]

Hi @maciejcieslik Maybe you can give me some information on your version? For me, HTML comments are the usual HTML comments.

[maciejcieslik]

VSCode version: 1.38.1

[budparr]

I see what you're saying. Being that Hugo templates are in HTML, I'm not sure that's possible. However, the way I make comments in HTML is command / (mac, not sure in windows/linux). Maybe that will help.

[maciejcieslik]

Plugin should have configurable shortcuts - now it is with conflict with default vscode shortcut or add hugo snippets only in hugo projects, not all html files.

[budparr]

Thanks, @maciejcieslik We'd really welcome a PR on this.

[jmooring]

@maciejcieslik,

If you like this extension's code highlighting, but would prefer to disable the snippets, use the Control Snippets extension.

Disable or enable VS Code's built-in snippets and manually installed snippets from extensions.

[jmooring]

@maciejcieslik,

Another option is to disable (not uninstall) this extension, then enable it for one or more workspaces as needed. Details here...

[wolfspyre]

@maciejcieslik,

Another option is to disable (not uninstall) this extension, then enable it for one or more workspaces as needed. Details here...

This feels like the best overall guidance, although I'm totally open to being proven wrong...

Given that one would want a hugo-scoped-editor-enhancer to be able to decorate/alter potentially any file within hugo's ability to consume, this plugins' filetype constrains aught be pretty lax and its applicability pretty universal within those contexts...

Might it be beneficial to this stance it a step further?

IE: have this plugin disable itself globally by default, and have a blob of 'add this to a hugo project's /.vscode/settings.json to enable it` in the readme?

Mindset being something along the lines of:

This plugin assumes that when its enabled, the user will want the hugo sugar ubiquitously available; which can conflict with other parsers/highlighters. Correspondingly, we adopt a default off behavior so as to not unintentionally clobber other non-hugo projects a user may also use vscode to alter

• The enablement effort expended is fairly small and only needs be done once-per-project;...
• Requires EXPLICIT enablement at a project level, and as such, allows the plugin to consider a much wider swath of content fair game for applicability
• provides a clearly described mechanism of enablement and preference-store and bounds the plugin's scope to a project which is more than less aligned with the editor's philosophy..

or I spoze this could be a terrible idea / waste of everyones' time... ¯\_(ツ)_/¯