Live data from Hacker News

The Plain Text Project

plaintextproject.online

141–150 of 208 posts

Re: The Plain Text Project

#141
post #117
post #15

I think more and more people are realizing that simpler is almost always better, and not only when it comes to software. I've found that this approach works best for nearly all aspects of life. The hard part is simplifying complex things. We have so many odd pieces (usually due to legacy reasons or conflicting designs) which don't quite fit into an otherwise simple solution. Plain text could probably work for most fo…

I don't think the UX needn't be complicated. If you really wanted that you can use .rtf, but whitespace and at least grayscale separation are already possible in plaintext of course. Want a cute header? How about: ########## Header ########## Smaller plain text files + folders are great for separating, categorizing, and interacting with information. Got another file type relevant to that note? throw it in a folder wi…

It’s worth noting that unless your header text file is in a format that can be converted to HTML, there’s no easy way for third-party accessibility tools to understand your plain text the way you do. Accessibility is one of the reasons WYSIWYG is so common. It’s hard to translate plain text to a semantic verbal description (though with AI and pattern matching this might be getting easier), and even harder if it’s not actually text. ¯\_(ツ)_/¯

Re: The Plain Text Project

#142

Earlier quoted context omitted.

I've switched to pass + git for my task list, diary, notes, creative writing. And of course passwords. It's working far better than the mix of things I was using previously.

Ditto. I use working copy for accessing a git repo where I keep notes on my phone. It’s a great little app. The only downside is I sometimes forget to commit and push, then expect docs to magically show up on my Desktop. I also wish it were a bit easier to add templates. I’ve been building a markdown interpreter on top of that repo to parse some of the more structured parts of my journal into little graphs and things…

I've done this[1], it works super well. The templating and automatic git management makes it seamless to work with. Hopefully my codebase is enough of an inspiration for you to make your own tool!

[1] https://github.com/ghthor/journal

Re: The Plain Text Project

#143
post #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.

One advantage I can think of is it doesn't need to be parsed into a node based tree structure like JSON. It's a lot easier to stream parts of it at a time.

Re: The Plain Text Project

#146
post #33

Recently I decided that I was going to solve the problem of: I easily write inline TODO comments while I work on code, but then have difficulty keeping track of them and getting my head back into the state of things later. While there is IDE support for such things, it's usually not exactly the right interface I want. So I made a tiny CLI app that scans the source for TODO and FIXME lines and presents a menu of files…

You reminded me of the time one cool guy and a respectable troll ran a script to create tons of issues on github for TODO comments in the code. He quickly got banned and the issues removed, but I for one was thankful to him. I think I asked the staff to get them back for my repo, but no :)

Re: The Plain Text Project

#148
post #9

Earlier quoted context omitted.

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.

if the dataset is "more structured" you can try to simplify this structure for great gains. As a byproduct, you get to use text files for the data.

Could you give an example?

Re: The Plain Text Project

#149
post #2

Except it's html. They didn't serve text/plain. I do get that thinking as words helps but isn't org mode or markdown plaintext?

That would be text/markdown :) Although serving markdown as text/plain should be totally fine if the client is a web browser. It would be incredibly useful if web browsers rendered text/markdown natively, though - mine renders PDFs, so I think the precedant's there.

Re: The Plain Text Project

#150
I switch to bear as it is text based with tag. I think similar text based and Cli would be useful and may be better than using a too specific And structured format.
Post reply on HN