Suggestion: Use a more obvious default deliminator for threads
IstoraMandiri opened this issue · comments
What’s missing?
Currently the default deliminator to separate threaded tweets is ---
, which is identical to what is used for defining Front Matter blocks.
While the docs do mention the deliminator can be customized, to reduce mistakes for new users by making threads easier to parse and debug, a more obvious default deliminator should be used.
Why?
As demonstrated below, it can be difficult to parse for a series of tweets that include Front Matter.
---
media:
- file: thread.jpg
alt: A giant ball of yarn
---
🧵 Here is a thread...
---
---
media:
- file: cat.jpg
alt: A cat
- file: dog.jpg
alt: A dog
---
Here are some cute animals!
---
---
poll:
- Banana
- Mango
---
Which fruit is more delicious?
---
What just happened?
Suggested Alternative
Use some more obvious default deliminator such as ______
.
---
media:
- file: thread.jpg
alt: A giant ball of yarn
---
🧵 Here is a thread...
______
---
media:
- file: cat.jpg
alt: A cat
- file: dog.jpg
alt: A dog
---
Here are some cute animals!
______
---
poll:
- Banana
- Mango
---
Which fruit is more delicious?
______
More difficult to misread, no?
---
is the standard delimiter used to split documents in YAML, that is why it is the default delimiter here. I do not think it would make sense to change that.
The .tweet
file itself isn't YAML though - only the contents of the Front Matter block is.
Indeed, but that's why I chose to use ---
as the default though, given we're already working in a context where yaml is being used. Any change to the default delimiter now would be a breaking change for the library, so I'm not really sure it makes sense to change it.
Fair enough with regards to backwards compatibility.
Perhaps an optional project-wide configuration option could be a compromise.
Ooh yah, project-level configuration would probably be useful for this and some other things (e.g. the tweet/media directory location/names etc.) -- I wonder if that should be a file, or just options passed into the action in the workflow?
Unless there are more complicated configuration options, for now just pass it to the action a workflow config environment variable?