Hey folks, I'm the engineer who implemented the new feature. Just clearing up some confusion.
A lot of you are noticing the preexisting automatic detection feature from 2022 [1], which I also worked on. That's NOT what this newly announced feature is. The new feature supports full import/export, but it's still rolling out so you're likely not seeing it yet!
I can't speak to the reasoning for announcing before 100% rollout, but I can say that the slow rollout is for safety. That way if there's a severe bug, then we can catch it while it affects a small number of users, instead of all users.
Labs is more for experimental features that needs more beta testing before rolling out to everyone, rather than being the "first stage" of slow rollout.
I wish we could opt-in to get early access in the slow rollout. That way you get the enthousiastic users to promote the incoming feature and you get some tech savvy people to test it before it reaches out more people.
It is a bit odd how they do it in Docs. In Cloud, announcements happen when the feature has already fully rolled out. Note, this is separate from region expansion, which might be delayed for some heavy-weight features (like new categories of VMs requiring special hardware.)
I work at Google in open source so I am constantly converting Google Docs to Markdown to put them on GitHub and vice versa. This will save me a lot of effort.
Will the API support uploading conversion of markdown to "application/vnd.openxmlformats-officedocument.wordprocessingml.document"? I process thousands of documents each month -- often have to parse from HTML to Markdown to Docx then finally upload and convert to Google Doc format.
Question: when coming up with tests (whatever level they might be) before you submit your code, what’s your thought process about what tests to include? What edge cases to handle? What to not test? Is there much disagreement about what to test?
I would say there wasn't much disagreement there. I typically started out by writing tests for the simple cases, then I would identify edge cases through actual usage of the feature locally, and write tests for those as well. Also, whenever bugs were found, I would write "regression test cases" for those when fixing.
When I export Markdown, the image reference is placed like `[image-1][base64-reference]`. However, the reference links should be `[image-1](base64-reference)`. The brackets for the reference should be parentheses, not square.
Is this also available from the googlecloud APIs libraries? Would be neat to be able to create a Google Doc from markdown content, it's something we were going to look into for one of the things we are building.
I would have expected this to export CommonMark, but it seems like it's not quite up to that yet. Is that on the board for a future release?
This isn't to say I prefer CM -- because Markdown came into being from Gruber's script. In a literal sense, "Markdown" is defined as whatever `markdown.pl` is, warts and all -- however, contact with the outside world forced things to move in a direction that is (so to speak) more organized that what John originally wrote.
We export to the closest available thing (e.g. file chips become links, people chips become mailto links, etc.) or drop the content entirely if there's truly nothing it can be converted to (rare case)
I just wanted to say, it took me a while to discover it (it happened by accident), but the preexisting feature from 2022 was a joy to discover! I didn't know you obviously, but I praised the kind anonymous soul out there who did that. I discovered it about 6 months ago, and I use it all the time now. I'm super excited to see it progress!
The docs for `libfloof` state:
> The floof is 4 bytes long, at most.
And when I type `code` with backticks at the start of a line, the word 'code' is formatted as code as expected, but auto-correct automatically capitalises it to 'Code' — which should never be done with code fragments.
So this is basically just headings, italics, bold, and links?
It's really annoying when you need to share technical documentation with lots of code and code-like content with people and they've started doing the spec in Google Drive. Just give me working Markdown.
To add a code block, type @ and scroll down to "Code Block <>". It's still very limited, with syntax highlighting limited to C/C++, Java, JavaSript, Python.
Is that available only in certain paid versions of Google Workspace, or has it not rolled out to everyone?
When I type @ there's no code block option. I get People, Smart Chips, and then in "Building Blocks" I get five items from "Meeting Notes" to "Project Assets". If I click the arrow to expand to the full list of building blocks, it only adds a sixth item "Launch Content Tracker" and the rest is blank space.
What would ``` add that you can't already do with two indents?
Beyond that, I think support for ```sh type highlighting would be awful, one of the best things about HN is how clean it is, I'd hate to see syntax highlighting or pictures or whatever when scrolling.
> What would ``` add that you can't already do with two indents?
It would let me add those fences before and after the code I’m pasting instead of having to go and add spaces in front of every pasted line. On mobile adding the spaces after pasting is a bit fiddly. Then again, maybe it is a feature because it discourages pasting too many lines of code in many cases.
This is supported, but it's probably not rolled out to you yet. And once it is rolled out, you need to turn it on yourself. See the blog the developer linked to in a comment.
Also when I close a single line code with `, the formatting stays as if I'm writing more code. It should reset to whatever formatting was before the opening `
I used Hackmd in the past to share the draft of my book (1) and liked that people don't need to have an account to comment. Google Docs was no option as no markdown support and account required. The process worked well but I found Hackmd too expensive for just getting feedback. Stash looks promising for this use case.
(1) Written fully in Markdown in Obsidian at this point. I moved to Asciidoc since because of formatting. The early draft is still available on Hackmd though. Details in my bio.
We've used HackMD in my OSS project since Google Docs was failing us as far as version control goes. What's great is that you can sync a HackMD document to GitHub or similar, so you can collaborate on a document and then push it to a repo.
They also already have to support Gemini to Google Docs and vice versa so it makes sense they'd have to support Markdown in some fashion on the backend.
i hope they'll eventually support Mermaid (https://github.com/mermaid-js/mermaid) for creating diagrams directly within documents. i've been using it a lot for my markdown files and it works amazingly well with LLMs (e.g. asking LLM to generate the diagram representation of something using Mermaidjs)
If this is implemented properly it’ll be a game changer for collaboration on papers. Means one can write a paper with colleagues in markdown and then easily knit with pandoc/quarto. Cheaper than overleaf etc.
Asciidoctor has been much better received by my colleagues, primarily for the built-in support of a few technical writing features — admonitions, non-trivial tables, crossreferences, etc.
Multimarkdown has similar features so far as I know, but it has the same problem as Markdown.pl: written by one person, with a bunch of spot fixes and so isn't really reproducible or extendible by anyone else without running into bugs.
I recently used Typst and their own collab solution for a paper we worked on. While some features are still lacking it was a pretty good experience overall.
Because in my experience, the value of collaboration tools isn't versioning -- going back to an older version rarely happens.
It's the suggested edits combined with comments sidebar right there in the document, where you can have whole back-and-forth asynchronous discussions.
There's no obvious/easy way to have comment threads in markdown or in git.
And while you could, in theory, implement suggested edits as commits on a separate branch waiting to be merged in, the workflow for that would be pretty horrible -- are you going to create a separate branch and commit for every single edit? Since small edits are generally individually accepted, rejected, or further modified.
Because not everyone is interested in setting up a Pandoc/Latex toolchain. Overleaf almost solved this problem but they don't support Pandoc as a frontend and want money unless you self-host.
This would have been very useful at several companies I worked at as a product manager for release blogs.
I always start editing in gdocs because it's so much easier to collaborate on than any blog platform, but then you always need to copy/paste the content once final into the blog and nearly every time, it copies some elements of formatting into the rich HTML editor I don't want (fonts, font sizes, etc) while I do want some things (headings, bold, italics). It's usually easy to import markdown to blogs or trivial to convert it to stripped-down HTML that can be imported. One of the teams I worked on built a simple gdoc script to do this
Whoa, this is a huge, huge deal for me. This is going to make Google Docs incredibly more useful, and will provide some functionality that I've currently been working around using vim block editing and macros (hey now, vim mode is a great next project for google docs :-D). Ability to import/export as markdown will also be a game changer for less technical people who want to contribute to technical documentation. I strongly prefer technical docs to be in markdown and under version control, and that makes it hard for people. This doesn't solve the git learning curve of course, but that part is pretty manageable.
Thank you to the people who made this happen! May you continue your great work for a long time to come!
I don't really use Google products, so I find this particularly useful for collaborating with people who do. I can do my shit in Markdown, they can do their shit in Google, and we can easily transfer the content back and forth.
This is really useful! Hope they continue to add features. I don’t like directly writing markdown and would rather use a text editor like Docs or Word.
You are not alone :) For Microsoft Word you might find Writage plugin useful (https://www.writage.com) - supports all basic Markdown syntax, tables etc. and recently added support for math formulas.
I like to have AI auto-complete assistance from something like GitHub copilot, so I often compose markdown within PyCharm and then paste to Google docs. There seem to be zillions of “AI-writing” tools out there but I’m shocked that nothing has replaced the smooth functionality of GitHub copilot. Google docs with Gemini is not smooth at all. Tried obsidian plugins but they are janky.
Yes, and to import. You mess with the mime types when creating a document or exporting and the conversion operation happens. Standard gdocs APIs cover conversion of formats already with doc files as an example.
I guess most users of Google Docs have no use for this, especially the download as markdown. I wonder why they decided to add this feature for the tech crowd so late in the lifecycle of the product, feels almost like an Summer '24 intern project?
Agreed; given the timing, an intern project seems plausible. (It feels a bit more ambitious than a typical intern project though, and I'm not sure how many of those end up quite so user-facing.)
I can imagine one internal use case.
At Google, we use Google Docs heavily for design docs. After the system has been built, it's not uncommon to link to the design doc as supplementary reading material. But the design doc isn't intended to co-evolve with the system; at some point, we migrate the design details to our internal documentation pages (g3doc [0]), which serves version-controlled markdown files and often has a much lower barrier to entry.
Even though Google Docs is ostensibly collaborative, design docs are often used as a snapshot of an individual's engineering maturity as justification during performance evaluation and promotion, and so it's not typical for them to be updated substantially, years after the initial implementation is complete.
Speaking as someone with experience in enterprise software, I'd say there's a good chance it's because one or more large corporations were ready to migrate from MS Office to Google Workspace but that not having Markdown import/export would be a deal-breaker.
A lot of times when you wonder, "why did they add that feature?", that's why. A single large potential customer absolutely needed it because of whatever critical internal business processes they happen to have.
It's a major difference from software sold to consumers, where the aggregate consumer demand for a feature is generally more obvious/intuitive/explainable.
Collaborative editing of Markdown docs in GitHub / GitLab can be a pain. This is a huge game changer for technical writers. Admittedly not the biggest crowd, but hey...
Interesting announcement. Feels like some of it is just copy-pasted from a PRD. Not necessarily a bad thing (it's clearer than press release style), just the first time I've noticed it in a "bigtech" announcement.
This is a great feature (and probably related to reliance on markdown from all the LLM services). I do wish they'd add SVG import to slides though, that's been a top feature request for like a decade.
I hope the "new tab experience" is rolled out to non-workspace users too. The tab + markdown export combination would make Google Docs a great blog editor!
This is great, the other day I had to export to HTML from Google Docs and then import the HTML into some kind of Markdown generator. The result was mediocre, but usable.
They are supported (source: beta tested it internally). We use this markdown feature for some internal workflows where github flavor markdown syntax is used. We've tested this works and ourselves rely on it as well as some other markdown extensions.
There was partial markdown support (and still is) in gDocs today. AFAIK copy as MD was never supported. But this new feature is full round tripping into and out of gDocs as native markdown.
markdown is such an elegant markup implementation, i remember using bbcode on online forums which was ok but markdown i use all the time to keep notes and organise my thoughts. when i do consulting i summarise my work in a github gist.
3. Export a Doc as Markdown (from File > Download)
4. Import Markdown as a Doc (from File > Open or "Open with Google Docs" from Drive)
Which of these do you see as trivial? These all seem quite complex to me with many edge cases , incompatibilities and ambiguities, especially if there's an expectation that you can round trip losslessly.
A lot of you are noticing the preexisting automatic detection feature from 2022 [1], which I also worked on. That's NOT what this newly announced feature is. The new feature supports full import/export, but it's still rolling out so you're likely not seeing it yet!
Hope you like it once it reaches you :)
[1] https://workspaceupdates.googleblog.com/2022/03/compose-with...