twitter-together / action

:bird: A GitHub action to tweet from a repository

Home Page:https://github.com/marketplace/actions/twitter-together

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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?