fizzbucket

Sorry, what's your source for this?

I know! But I'm not interested in money, and it seems possible to provide something much easier to use then emacs, which, although inferior, can still help people who can't invest the time in learning to use emacs. (There's actually a sociologist, Kieran Healy, who's devoted lots of time to carefully explaining his emacs-centred workflow, with almost no uptake. There's just an enormous class of people who use Word -- horrendously inappropriate for this class of work -- when it's easier to make something much better, though still a long way off emacs.

Nope, ReText is not the project. But it has quite different goals. I'm actually an academic in the humanities (though lots of my work uses digital tools). I got so thoroughly sick of marking essays with shoddy referencing and inconsistent formatting that it seemed like there must be people who could use things like your example of auto-completing citations; that isn't the purpose of retext at all, and its goals are much more to help people who know what they're doing.

ReText is also not very cross-platform, in practice for Linux only, although it's possible to install on a Mac with effort. It might be more justifiable to work on improving it, but the maintainer isn't interested in pandoc support, which, first makes citations very difficult, and second, means submission either to academic journals or university tools like Turnitin is more complex then it needs to be.

Then there's just little things -- like quoting verse in Markdown, which requires two spaces at the end of each line. That's easy enough to make happen automagically, but it's a feature that would never be used by a typical ReText user, or someone using Mou or MacDown, so they're unlikely to want to support it.

Got the split screen live preview already; tree view sounds a very useful addition, though.

Extensions are also a good plan; the interesting thing is that many of them end up being routed to pandoc, so they can be done with document metadata in any case. For others, one easy thing to do might be to rewrite some of the bits in C++ in PyQt, then have the possibility of importing classes that inherit from the originals and override functions. Does that make sense, do you think?

Awesome; but what do you reckon the best way to implement a corkboard is when it's entirely possible that you're dealing with individual documents, not Scrivener's groups of them? (Sorry, that sounds snarky; it's a genuine question; one global corkboard, per folder, or what?)