

Text is Forever - A multi-platform approach to living a life in plain text - alexcabrera
http://marquee.by/alexcabrera/text-is-forever/

======
Derbasti
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.

~~~
alexcabrera
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.

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

------
blacksmythe

      >> 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/

~~~
alexcabrera
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.

