4 ms·

I believe the splitting of hairs is that plugins should build on top of core, solid, helpful primitives, and augment the core platform with esoteric things that

I believe the splitting of hairs is that plugins should build on top of core, solid, helpful primitives, and augment the core platform with esoteric things that the core audience wouldn't care about. That's not this plugin It also pragmatically makes for fragmentation in the experience, leading to the same outcome as the current LLM debate: "works great" "not for me"

IshKebab 1y ago
> augment the core platform with esoteric things that the core audience wouldn't care about. That's not this plugin Seems like it is to me. Storing code inside yaml is pretty obviously a terrible idea and I haven't seen many systems do it (beyond Bash at least).
- 9dev 1y ago
  That is not an argument. The same implementation could be used to highlight SQL queries in arbitrary code, for example. What you want is the general ability to have regions of nested code in a file that use a different language than the rest of the file.
  - IshKebab 1y ago
    VSCode does support that. It's up to language extension authors to implement it though because obviously only they know which bit of text is in which language. I don't think SQL queries in code is a very big use case and even there, any that are large enough to need syntax highlighting are probably better off in a separate file. The biggest use case of multi-language files I've seen is Vue single file components, but in practice they turned out to be a terrible idea precisely because of tooling issues like this.
    - 9dev 1y ago
      > VSCode does support that. It's up to language extension authors to implement it though because obviously only they know which bit of text is in which language. Wrong, proper tooling can infer that intelligently, or by having the user annotate it with a comment (e.g. #language=bash). > I don't think SQL queries in code is a very big use case […] You seem to have very little exposure to mature codebases, then. Embedded SQL without an ORM is widespread, still. You'll also find plenty of advocates on this very forum. > […] and even there, any that are large enough to need syntax highlighting are probably better off in a separate file. That isn't up to the tool author to decide. > The biggest use case of multi-language files I've seen is Vue single file components, […] …and HTML files, YAML config for CI pipelines, database migration scripts, DevOps configuration files, Postgres extensions, … > but in practice they turned out to be a terrible idea precisely because of tooling issues like this. > The Vue ecosystem is very well and alive; also, proper tooling is very capable of solving issues like this.

IshKebab 1y ago

> augment the core platform with esoteric things that the core audience wouldn't care about. That's not this plugin Seems like it is to me. Storing code inside yaml is pretty obviously a terrible idea and I haven't seen many systems do it (beyond Bash at least).

9dev 1y ago
That is not an argument. The same implementation could be used to highlight SQL queries in arbitrary code, for example. What you want is the general ability to have regions of nested code in a file that use a different language than the rest of the file.
- IshKebab 1y ago
  VSCode does support that. It's up to language extension authors to implement it though because obviously only they know which bit of text is in which language. I don't think SQL queries in code is a very big use case and even there, any that are large enough to need syntax highlighting are probably better off in a separate file. The biggest use case of multi-language files I've seen is Vue single file components, but in practice they turned out to be a terrible idea precisely because of tooling issues like this.
  - 9dev 1y ago
    > VSCode does support that. It's up to language extension authors to implement it though because obviously only they know which bit of text is in which language. Wrong, proper tooling can infer that intelligently, or by having the user annotate it with a comment (e.g. #language=bash). > I don't think SQL queries in code is a very big use case […] You seem to have very little exposure to mature codebases, then. Embedded SQL without an ORM is widespread, still. You'll also find plenty of advocates on this very forum. > […] and even there, any that are large enough to need syntax highlighting are probably better off in a separate file. That isn't up to the tool author to decide. > The biggest use case of multi-language files I've seen is Vue single file components, […] …and HTML files, YAML config for CI pipelines, database migration scripts, DevOps configuration files, Postgres extensions, … > but in practice they turned out to be a terrible idea precisely because of tooling issues like this. > The Vue ecosystem is very well and alive; also, proper tooling is very capable of solving issues like this.