Add engine specific delimiters

colinbate commented

2018-04-30 18:42:34 +00:00

(Migrated from github.com)

This PR does make some changes to the nature of matter.language(), which probably isn't desired. I can remove that and make another method for this if necessary, but I thought I'd get a working version out there for review.

Files parsed with custom delimiters should round-trip via stringify correctly.

This PR does make some changes to the nature of `matter.language()`, which probably isn't desired. I can remove that and make another method for this if necessary, but I thought I'd get a working version out there for review. Files parsed with custom delimiters should round-trip via stringify correctly.

jonschlinkert commented

2018-05-01 12:37:29 +00:00

(Migrated from github.com)

This is a great start! Nice work.

This PR does make some changes to the nature of matter.language(), which probably isn't desired.

I'm thinking we should allow users to decide how they want to specify the engine to use:

via delimiters
by specifying the language after the first "fence"
options

The main goals are performance and reliability, as long as it satisfies those two things I'm open to whatever approach you want to take. Although I'd probably favor options versus additional methods.

This is a great start! Nice work. > This PR does make some changes to the nature of matter.language(), which probably isn't desired. I'm thinking we should allow users to decide how they want to specify the engine to use: - via delimiters - by specifying the language after the first "fence" - options The main goals are performance and reliability, as long as it satisfies those two things I'm open to whatever approach you want to take. Although I'd probably favor options versus additional methods.

colinbate commented

2018-05-01 17:32:15 +00:00

(Migrated from github.com)

Previously, if you specified the language after the fence in the front matter, it would override the language passed into the options. With this change, any recognized custom delimiter will also override the passed in language. After thinking about it seems okay, it is the document which gets to specify the language, and the options are just providing the fallback language. So on that front, all is fine.

The issue with matter.language() is that it now requires the full file contents as its first parameter. Previously it would work with a string which had the initial --- fence trimmed off. Also, the object it returns has an additional property, but that isn't a big deal. What is different about the return value is that the raw property now includes the whole fence: ---coffee vs. just coffee as before. Let me know if this is a concern; I could make the changes fully backward compatible if necessary.

As for performance, the cases where there is front matter with a default delimiter should be unchanged. The only situation which would be affected is if you have a string or file without any front matter, and you have many engines defined.

I've pushed a small tweak to ensure you don't register a custom engine delimiter the same as the default one.

Previously, if you specified the language after the fence in the front matter, it would override the language passed into the options. With this change, any recognized custom delimiter will also override the passed in language. After thinking about it seems okay, it is the document which gets to specify the language, and the options are just providing the fallback language. So on that front, all is fine. The issue with `matter.language()` is that it now requires the full file contents as its first parameter. Previously it would work with a string which had the initial `---` fence trimmed off. Also, the object it returns has an additional property, but that isn't a big deal. What is different about the return value is that the `raw` property now includes the whole fence: `---coffee` vs. just `coffee` as before. Let me know if this is a concern; I could make the changes fully backward compatible if necessary. As for performance, the cases where there is front matter with a default delimiter should be unchanged. The only situation which would be affected is if you have a string or file without any front matter, and you have many engines defined. I've pushed a small tweak to ensure you don't register a custom engine delimiter the same as the default one.

colinbate commented

2018-05-01 19:46:15 +00:00

(Migrated from github.com)

I didn't regenerate the README file, but I did update the underlying verb file. I wasn't sure if you normally do that. The output differed in a couple of ways, so I didn't want to presume.

colinbate commented

2018-05-16 02:06:44 +00:00

(Migrated from github.com)

@jonschlinkert Just checking in to see if you've had a chance to look at this further. I think it is mergeable, just let me know if you want me to regenerate the README or any other housekeeping.

colinbate commented

2020-06-01 19:45:44 +00:00

(Migrated from github.com)

Just revisiting this as I’ve come across another place where I’d like the per-engine delimiters.

This pull request has changes conflicting with the target branch.

gray-matter.d.ts
index.js
lib/stringify.js
src/delimiters.js
test/matter.language.js
test/parse-toml.js
test/stringify.js

View command line instructions

Manual merge helper

Use this merge commit message when completing the merge manually.

Merge commit title

Merge pull request 'Add engine specific delimiters' (#75) from colinbate/per-lang-delims into master

Merge commit body

Reviewed-on: https://repo.reapertech.com/rtlabs-llm-agents/gms-gray-matter/pulls/75

Merge pull request 'Add engine specific delimiters' (#75) from colinbate/per-lang-delims into master

Reviewed-on: https://repo.reapertech.com/rtlabs-llm-agents/gms-gray-matter/pulls/75

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin "colinbate/per-lang-delims:colinbate/per-lang-delims"

git switch "colinbate/per-lang-delims"

Rows
Columns

Add engine specific delimiters #75

Manual merge helper

Checkout