Shameless plug: I worked on a similar tool mdocs [1]. The main difference is that is opensource, it supports authentication and authorization [2] similar to Google Docs. The authorization part allows you to share documents at company level.
It is a 100% client-side application, it uses Firebase as backend and Auth0 for authentication.
[1] was really confusing. It consistently errored when I tried to sign in, then when clicking the link for more details, walked me through creating an auth0 account. I did find [3] which made more sense.
It uses a theory called Operational Transformation [1] which is roughly the base for most collaborative tools like google docs.
My first attempt was using a library called ot.js [2], I changed it to support an async db since it only supported a in-memory store and I adapted to use mongodb. The experiment is in [3] and it has some bugs still.
Then I found out the guys at firebase adapted ot.js client side to work with their own db, and created something called Firepad [4]. So, I used that instead which was more stable and I added auth and authn.
Collaborative editing is great, and I wonder if this project could be adapted as some sort of browser extension that would allow teams to collaboratively edit on pages that don't otherwise support it.
For instance, the project-management software my team currently uses does not allow us to collaboratively edit tickets. Sometimes we've resorted to writing tickets together in Google Docs and then transferring the text back into the project-management tool. It would be awesome if we could use Fiddle.md or a similar tool right there on the page, rather than having to transfer text between tabs.
Hey, I'm one of the co-founders at Swipe, thank you so much for the comment! That's a really interesting idea. Our scope with this is very narrow now and we wouldn't want to promise something like that at the moment. But it's something we haven't thought about before, it sounds really useful.
.md is the ccTLD for my country (Moldova), which got me excited and confused for a bit - was trying to find the connection with music in Eastern Europe. I'm not sure how to feel about such ccTLD abuse and conflating TLDs with file extensions in general.
While it would be nice if websites always had some connection to the country whose TLDs they're using, I think that ship has sailed. I wonder what someone from Tuvalu would have to say about it though. They handed out a lot of the best TLDs before anyone had any idea what to do with the Internet.
For custom CSS, a user-level workaround for now could be to style the domain with your userContent.css (Firefox) or the Stylish extension (Firefox, Chrome).
I'm using it today for a sales document, it's sweet.
Well, there are some more complex yUML diagrams on the yUML samples page that don't work. It's probably yUML's fault because the syntax isn't quite "proper". But it would be nice if fiddle.md had a way of embedding yUML DSL. E.g.
==== yUML Class Diagram ====
[Company]<>->[User]
[Company]<>->[Record]
[User]-.-[note: A regular user]
==== end ====
I'm confused how this is collaborative. If a friend sends me a fiddle.md link and I change the content of the document, how do they become aware of my changes? Do I send them my link back?
We tried to approach collaboration in a very simple way that doesn't require accounts and heavy realtime Google Docs-style co-editing. Our collaboration relies on versions and links. Every refresh creates a new version, so as soon as you pass a link to someone, they create a new version automatically. This way you're never editing the same version, even though you're editing the same "document". So it definitely is based on passing links around but making sure there are no conflicts. We're definitely looking into simple ways to notify you that there's a new version created by someone else so it runs even smoother.
You can think of it a bit like a tree system, where you start on the stem and as you share it with others you build independent branches. Hope it makes sense, we're definitely going to work more on that part in the future.
As an academic that writes in Markdown (usually solo, offline), this ticks so many boxes for me. I love that for once I may be able to convince my co-authors to collaborate in Markdown instead of Google Docs. Integration with Dropbox is crucial to accomplish this (most academics use Dropbox), but it is missing one step: IMPORT!
It's great to see that I can export to Dropbox, but then how do I roundtrip? Rather than remembering the URL (or copy and pasting from a desktop app), it would be great to be able to load up an existing document from Dropbox, send off a collaboration link, and then have the ability to send the completed (collaboratively written) text back to Dropbox.
As soon as the content is over a page long, the "preview" doesn't really work, since what is supposed to be previewed is out of bounds.
I had developed a few years ago a markdown editor with live preview, with a mechanism that synchronized the source and the preview, scroll-wise, so the preview would always display the part that was being edited.
It didn't take off (at all) so I let it go, but I wish there would be a standardized way to do this.
> It should be possible to scroll in the preview section, and then keep typing...
Yes of course, that works, but you have to scroll manually.
Maybe I don't write the way other people do, and that's why I need automatic sync and most people don't: I don't write linearly, I write "all over the place".
I constantly go up and down a document when I'm writing something: what's getting written at the bottom impacts what was written at the top. Also I think of better ways of saying something once I've written it, and once I do I need to make changes.
If, every time I change sections, I need to scroll the preview, it's incredibly distracting/annoying (or, useless: but then it's better to have no preview at all).
Also, once a document is of any serious length (say, over 3 pages), finding the part where you are in the preview can get a little difficult.
The only thing that prevents me from using this that I can't make an account to save my documents, and I can't get that url bar to go away. The giant bar that says "fiddle.md/b836w36wh2h8mv3fj23t8r/edit" even though I can already see the link in my own URL bar. If there were a way to remove that I might use this. Looks great though!
That's definitely something we'd want to add. At the moment we wanted to release an MVP and see if people like it before adding accounts and other features. We didn't think it was crucial to getting the core experience with the product, but we're going to keep improving it over time. For now, you could save locally or to Dropbox to avoid losing revisions. Thank you for the comment, I'd recommend signing up to the mailing list to hear about when things like accounts would launch.
I love MD support, it makes writing things easy and looks polished, therefore I love this!
On top of that I believe It's going to make it onto swipe.to ? I hope so because it would be a a much needed addition tool for editing presentations and rendering it on the fly :D
No offense and all (I'm a huge python guy) but... why? RST is a pretty god damn awful format. Markdown lacks a proper standard but that's really the only problem with it... I wish the python community would just adopt Markdown for good and stop trying so hard with rst.
I've wondered about the same question, and I also personally greatly prefer markdown. I got into Python in 2002, and my recollection is that RST was introduced a few years before Markdown. Thus RST was more mature than Markdown at the time when Python documentation was a disaster zone and people were looking around for technology on which to build Sphinx. So I think RST versus Markdown for Python is more or less a "historical accident"; by now, there's a massive amount of documentation in RST, and it's too hard to switch everybody over. This situation reminds me somewhat of how Python uses Mercurial instead Git (see [1]); many years ago it was unclear whether Mercurial or Git would "win", and in fact many people (at least myself included, with SageMath!) thought incorrectly that Mercurial would win. Hindsight is 20/20, and fixing making the wrong bet on which technology will win can be extremely painful (at least it was very hard for us to switch SageMath from Mercurial to Git).
Yeah you're absolutely right. RST was great when Markdown wasn't around, but Markdown is just better.
It's a bit of a toughie, the python community doesn't have much to deal with Markdown itself. pypi expects rst etc. There's also very few tools available in general, which is a huge shame.
Part of this is due to different Markdown "flavours". At this point though, Github being the largest provider of Markdown, a safe bet would be to standardize on Github's flavour and call it a day.
> I got into Python in 2002, and my recollection is that RST was introduced a few years before Markdown.
That's true: According to Wikipedia RST is from 2002 (so is AsciiDoc), Markdown from 2004. Perhaps also important though is that RST was introduced as a direct successor to StructuredText, which apparently, had some currency in the Python community previously.
Actually, I completely disagree. Rst can do things that markdown will never be able to do (at least, not any of the common dialects). E.g., you can create your own directives to do special formatting however you'd like. You also have a ton more functionality built-in (e.g., a directive for LaTeX-style math) that is also incredibly uncommon in markdown.
Furthermore, the document structure in rst is far more powerful (e.g., you choose your heading conventions).
As it turns out, I am not actually a huge fan of python (and there are plenty of problems with rst), but in the comparison between mdown and rst, the only argument I actually see in favor of mdown is that it's more commonly used (though the fact that commonmark has yet to completely take over actually mitigates that a fair bit).
I can see how you might feel that way about some of it. But I actually do not really find that to generally be the case. And plenty of it is far nicer than Mdown.
However, this is jumping into completely subjective territory; you, of course, do not have to like rst, just as I do not have to like mdown. So, I will stick with my original sentiment of wishing these services would support the thing I like :)
My syntax comment was a bit abstract, apologies about this. I'm referring to RST's strictness and how painful it is to deal with, for example, something as simple as links. I don't really care which way you bold or italicize words, really...
SageMathCloud (https://cloud.sagemath.com) has similar functionality (collaborative editing, preview) and supports restructured text. To try it, create an account, project, and new file that ends in .rst. It renders the rst server-side using rst2html in Linux, so isn't instant (since not in Javascript) -- are there any good rst to html converters written in Javascript? SMC also runs aspell (server side) when the file is saved.
Here's a screenshot: http://wstein.org/misc/smc-rst.png of https://cloud.sagemath.com/projects/4a5f0542-5873-4eed-a85c-...
(Disclaimer: I started SageMathCloud and SageMath. SageMath uses Sphinx for documentation, hence we care about RestructuredText editing.)
Just as a quick note for you. Be aware that certain directives in rst can be security risks if you allow them to be run arbitrarily by users. If you haven't already done so, you should probably look into that.
This seems like an interesting service, I will need to take a look at it, thanks!
Thanks for the feedback! We started with Dropbox because that is what we all use, but we do want to add support for other services. Your idea for GitHub integration is very interesting, and it's not something that previously occurred to us. It's something we'll definitely look into!
I love the syntax helper in the bottom. I've added markdown to a few projects and usually, I just added a help text summary near the input to remind users of the syntax; this is a much better solution.
Really like the design, especially the search/menu box.
It would be very nice to add proper support for tabs, especially when inserting larger blocks of code.
Thank you for the comment! The project actually started as we were building a tool to teach people Markdown a la Codecademy. We realized this probably does an equally good job at that too.
Although, table-support seems to be very limited. The table is generated correctly, but it doesn't look nice enough. Take a look at LightPaper for inspiration.
The HTML generated correctly, but the actual table didn't render at all in the preview for me. Text was aligned...sort of, but there was zero white space, and no dividers. Maybe it's simply my rusty MD skills.
It is a 100% client-side application, it uses Firebase as backend and Auth0 for authentication.
[1] https://auth0.github.io/mdocs2
[2] https://dl.dropbox.com/s/w6bmji4t698v8qn/ss-2015-03-25T10-40...