Back in the late 2000's I looked around for the right tool for my Ph.D. dissertation and quickly ruled out Word, Libre (or Open Office) Writer, or any wysiwyg tool, because they 1) lacked fast, easy ways to work at the structural (tree) level of the document, which is important when you have many sections and subsections to organize thoughts and arguments; 2) couldn't do mathematical notation well; 3) didn't integrate well with the reference management tool I was using then, Mendeley.

As an Emacs lover, I soon found Org, and it was (and remains) the perfect tool, for working in plain text — which will never be obsolete, and works easily with git or version control. Then and now, nothing could match Org speed and flexibility: structural editing (creating nodes, moving nodes, promote/out-dent a node, demote/in-dent a node) was and is fundamental to Org (unlike Markdown etc), and it's ridiculously easy to reorganize thinking and writing as you go. You can export to LaTeX (or HTML) and customize formatting as needed, while also including code blocks from multiple languages. Integration with BibTeX was tight, and made handling hundreds of references easy.

Where other writing tools for complex documents previously made me cringe and cuss, Org makes writing a pure joy, freeing the mind to work entirely on content and its structure.

Character (integrity, drive to learn & improve) and skills that you respect or admire. Then shared values and life situation: the startup should be the #1 priority for everyone on the core (full-time) founding team. Missing any of those requirements increases the risk of failure.

Unfortunately for those without a wide/deep network of college friends, former colleagues, etc. it's hard to judge character and skills without a previous friendship or shared work environment, etc. If you're forced to evaluate a potential co-founder in the absence of shared history, work on something small together for a few days/weeks and see how it goes.

Another thing to do in all cases is to discuss downside/failure scenarios right up-front, and see if there's a sense of openness and fairness. Check out the books The Founder's Dilemmas and Slicing Pie for structuring the conversations, as they give vital ideas and precedents around formalizing the founders' relationships. It's much easier to chat about failure and equity before real work starts, and I've seen many times that it flushes out assumptions and behaviors that you won't want on your team (assuming you're the reasonable and fair one :-).

Shameless plug: more examples of literate Clojure in Emacs here, https://github.com/limist/literate-programming-examples

It's not bad - I read this book a while ago to boost my Python-fu. But it left me feeling like most software/language books - unsatisfied, i.e. here are the pieces (syntax), here are a few (boring, trivial) ways to put the pieces together, etc. To give a really strong CS foundation, SICP still rules. :)