Text is Forever - A multi-platform approach to living a life in plain text | Hacker News Reader

Text is Forever - A multi-platform approach to living a life in plain text

marquee.by

16 pointsalexcabrera5 comments

So, this is basically a thoughtful list of text manipulation programs for the Mac. And a great list at that.

I was astonished and slightly embarrassed to find out that my personal answer to all his use cases are Emacs.

Still, I fully concur with his sentiment: Text encoding issues aside, the only data format with sufficient longevity and compatibility for long time storage is plain text. It is what drives technology. It is source code. It is markup. It is the universal format for communicating with computers and humans.

That said, a smattering of HTML or LaTeX can go a long way to make plain text more printer/reading friendly.

I think it's important to have your core text editor - the thing that makes you a living - be something that you can take with you anywhere. You're pretty much looking at vim or emacs in this case.

I think of HTML as an output format more than anything else. LaTeX, while powerful, is terrible for reading what you've authored. That's why Markdown is so appealing, it's a semantic syntax rather than markup; it's easy to write, easy to read, and has the added benefit of being programmatically processed.

Kudos for not reducing this to a vim/emacs flamewar.

One could argue that Sublime Text or JEdit could be an option, too.

  >> you put a text file in Dropbox, and it showed up as a formatted page on the web

It's pretty easy to configure a generic Jinja2 HTML template, then run the markdown and Jinja2 python modules on any markdown file to turn it into a web page.

A framework is hardly needed, but these exist if you don't want to configure a solution:

  Jekyll, Hyde: http://philipm.at/2011/0507/

  Pelican: https://pelican.readthedocs.org/en/latest/

Jekyll and Hyde are both awesome. I played around with Pelican a while ago, and it seemed solid.

Droptype wasn't much more than that. It used Dropbox's then-new revised API to look at Dropbox/Apps/Droptype and then displayed any Markdown files as a list. If you added a README file, it would render the contents of that. It was a quick and dirty Django app.

There wasn't any control over the design or any web-based editing capabilities. Others are doing interesting stuff in that space, most notably http://scriptogr.am/ which is probably a lot like where Marquee would have ended up if we continued to go keep going down that route. They're doing a very nice job with it though.

That said, we're looking at Dropbox/GitHub integration as more of a feature than a product. We're approaching the problem space from a somewhat different direction; the focus on our authoring environment is the first step to getting there.

Reply on news.ycombinator.com