Live data from Hacker News

The Plain Text Project

plaintextproject.online

1–10 of 208 posts

Re: The Plain Text Project

#3
not to be That Guy, but: all those things listed under each bullet are very nearly just org-mode documentation chapter titles.

Org is very clearly Just Plain Text, but there is a nontrivial caveat, which is "... backed by LISP, so text is also data is also code is also text". Most of the real goodies (babel, refile, capture) will not (ever, probably) work outside of emacs.

I agree that plain text is rad, though!

Re: The Plain Text Project

#4
I never thought of plaintext as a way of life, but I think I agree with it in principle (as many others on here probably do.) I didn't know I was part of a movement, but I did write my own simple (and open source) hours tracking/invoicing tool on plaintext principles: https://github.com/ses4j/ts

Re: The Plain Text Project

#5
Great collection of tools and articles. Plain text is also a great (and the best) choice for datasets. Do NOT use JSON, YAML and friends, for example, as your input format but use plain text with a custom parser to import into any SQL database and than you can easily export to JSON, YAML and friends. See the football.db and the Premier League or World Cup match schedule as living examples [1]. [1]: https://github.com/openfootball

Re: The Plain Text Project

#6

Great collection of tools and articles. Plain text is also a great (and the best) choice for datasets. Do NOT use JSON, YAML and friends, for example, as your input format but use plain text with a custom parser to import into any SQL database and than you can easily export to JSON, YAML and friends. See the football.db and the Premier League or World Cup match schedule as living examples [1]. [1]: https://github.com…

As great as such formats are for human consumption, they should come with reference specifications and parser implementations to be usable.

Re: The Plain Text Project

#9

Great collection of tools and articles. Plain text is also a great (and the best) choice for datasets. Do NOT use JSON, YAML and friends, for example, as your input format but use plain text with a custom parser to import into any SQL database and than you can easily export to JSON, YAML and friends. See the football.db and the Premier League or World Cup match schedule as living examples [1]. [1]: https://github.com…

If your dataset is mostly a list of strings, sure. If it's anything more structured, why exactly?

I'd argue that using "plaintext" for structured data (a.k.a, inventing your own data representation) will set up both you and the users of your dataset for unnecessary pain dealing with unescaping and parsing.

Post reply on HN