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...
[3] http://mdocs.io/
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.
[1]: https://en.wikipedia.org/wiki/Operational_transformation
[2]: https://github.com/Operational-Transformation/ot.js/
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.
- Allow custom CSS
- Post a json with the markdown content to a custom URL
Do you plan to open source it?
Example:
http://fiddle.md/c74bgs3vthgqm8mtt9kx3z
Not perfect, but wouldn't take much to make it play nicely?
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 ====
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.
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.
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.
Other than that, great tool! Thanks for sharing.
Which browser are you using? What is the bahaviour you're seeing? Does the preview "reset" to the top scrolling position?
Glad you like it :)
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.
Looking at this, I was wondering why this team didn't just fork that for their intended collaboration use-case (which is neat!).
The beauty of Markdown is that it's simple text; this is distracting and a little unpleasant.
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
I see you currently support saving the fiddles to dropbox. Do you plan to add other storage systems?
I'm thinking it would be great to use that along with github to write documentation or even websites using jekyll.
Edit: It's back. Thanks for the patience.
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.
[1] https://docs.python.org/devguide/faq.html#where-can-i-learn-...
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).
http://commonmark.org/. Of course, you might already know about this, and just be playing the https://xkcd.com/927/ card.
On that topic, does anyone know what flavour of markdown is being used here (in fiddle.md)?
(Disclaimer: I started SageMathCloud and SageMath. SageMath uses Sphinx for documentation, hence we care about RestructuredText editing.)
This seems like an interesting service, I will need to take a look at it, thanks!
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.
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.
The syntax is horrible.
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 :)
Rst feels like a happy medium between mdown and LaTeX for me, which is actually very much how I use it. I use it in situations where I would have used LaTeX in the past (instances where mdown surely wouldn't cut it). Of course, there are some times (e.g., tables, figures and bibliographies) where LaTeX is the only sensible option, but for anything simpler, I'd still prefer the power that Rst gives me.
Additionally, I actually really like most of how Rst does URLs. It is definitely less simple than mdown, but it's so much more powerful and generalized.
