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!
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...