Allow engines to specify default delimiters for auto-detection #72

New issue

Open

opened 2018-04-24 17:31:54 +00:00 by colinbate · 2 comments

colinbate commented

2018-04-24 17:31:54 +00:00

(Migrated from github.com)

Currently, language detection is supported by specifying a parameter after the opening frontmatter delimiter (---lang). It would be great if engines could also specify a default delimiter alongside the parse and stringify functions. Then if no language or delimiter was specified via options, the engine could be chosen based on the type of delimiter.

In particular, I'd like to see support for using +++ to delimit TOML frontmatter which is fairly common.

Currently, language detection is supported by specifying a parameter after the opening frontmatter delimiter (`---lang`). It would be great if engines could also specify a default delimiter alongside the `parse` and `stringify` functions. Then if no language or delimiter was specified via options, the engine could be chosen based on the type of delimiter. In particular, I'd like to see support for using `+++` to delimit TOML frontmatter which is [fairly](https://gohugo.io/content-management/front-matter/) [common](https://caddyserver.com/docs/markdown).

👍 2

jonschlinkert commented

2018-04-26 11:47:45 +00:00

(Migrated from github.com)

I like this idea, I think we should be able to do this without any performance penalty. Labeling as a feature request for now, if you or someone wants to do a PR that would be great - it might be good to discuss approach first on this issue.

thanks for the issue!

colinbate commented

2018-04-27 19:21:41 +00:00

(Migrated from github.com)

I was thinking that matter.language() would be the place to add this. You would just check to see if the first line of the input matched the default delimiter (defined in opts or ---). If not, you would take the trimmed first line and check it against the list of engines (those with a delimiter given). The delimiter (pair) of the matched engine should be added to the language object returned, alongside name and raw. The call to matter.language() would need to happen a bit earlier in the parseMatter function, but otherwise, it shouldn't be too dramatically changed.

The only question I see is how to handle situations where two different engines provide the same delimiter. Error? Last wins? There is no real order to the engines object, so it becomes a bit undefined.

Also, there are a couple of places in the code where defaults(opts).delimiters is referenced and would need to be swapped out for file.language.delimiters (or something similar). This would also allow stringification of files with proper delimiters as well.

Any thoughts on this? I don't mind tackling it if there aren't any other takers.

I was thinking that `matter.language()` would be the place to add this. You would just check to see if the first line of the input matched the default delimiter (defined in opts or `---`). If not, you would take the trimmed first line and check it against the list of engines (those with a delimiter given). The delimiter (pair) of the matched engine should be added to the language object returned, alongside `name` and `raw`. The call to `matter.language()` would need to happen a bit earlier in the `parseMatter` function, but otherwise, it shouldn't be too dramatically changed. The only question I see is how to handle situations where two different engines provide the same delimiter. Error? Last wins? There is no real order to the engines object, so it becomes a bit undefined. Also, there are a couple of places in the code where `defaults(opts).delimiters` is referenced and would need to be swapped out for `file.language.delimiters` (or something similar). This would also allow stringification of files with proper delimiters as well. Any thoughts on this? I don't mind tackling it if there aren't any other takers.