（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=40982118

用户想知道 Google 协作平台是否像 Google Colab 一样支持 Markdown 输入单元。不幸的是，不可以，因为 Google 协作平台只允许纯 HTML。不过，用户可以使用 Pandoc 等工具将 Markdown 文档转换为 Google 协作平台，该工具可以转换包括 Markdown 在内的各种文件格式。此外，该用户还询问如何使用 MyST Markdown YAML 标题从 Markdown 文档创建 Google 协作平台页面。这可以通过构建一个静态站点生成器来实现，该生成器利用 GatsbyJS 或 Hugo 等工具将 Markdown 文件转换为可部署的网站。此外，用户提到 NotebookLM 可以生成 Python、LaTeX 和 Markdown 文档。他们想知道如何在没有容器或 Inspect 元素的 Chromebook 上执行 Markdown 和 Git diff。建议使用在线比较工具，例如 Unified Diff 或 Diffs.io，它们支持 Markdown 并提供类似于 git diff 命令的功能。在使用 Markdown 散文对 Jupyter Notebooks 自动评分方面，用户对 OtterGrader 很感兴趣，这是一个开源项目，它为使用 Jupyter Notebooks 的编程作业提供自动评分。要使用不同的 Markdown 文件类型（MyStMarkdown、RST、IPYNB）构建书籍，用户可以使用 Jupyter Book 或 mkdocs 等工具。最后，用户在 Google 文档中编写技术文档时对渲染代码片段的限制和自动更正问题表示沮丧。为了克服这些挑战，用户寻求可行的 Markdown 解决方案，最适合在 Google 生态系统中使用。顺便说一句，该用户提到 Google 大量使用 Google Docs 来编写设计文档。他们建议在系统建成后将设计细节移至内部文档页面。这些页面提供版本控制的降价文件，进入门槛较低。设计文档可能会随着时间的推移而演变，但通常在初始实施完成后被冻结，因为在性能评估和晋升期间被用作工程师熟练程度的衡量标准。

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!

Hope you like it once it reaches you :)

[1] https://workspaceupdates.googleblog.com/2022/03/compose-with...

The main effect of slow rollouts on me is that I never use the feature. It goes like this.

1. There's a service I use sporadically or used to use

2. They announce a new feature that might potentially mean I'll start using it again/more

3. I read the post, log in and realise I don't have access yet

4. I completely forget this ever happened.

Surely all the effort that goes into announcing these things is a bit wasted ?

What happened to the a nice "Labs" switch to opt into stuff that's new and a bit raw?

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

You are my hero.

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.

Is it possible to get this feature in Slides as well?

I often need to prepare technical slides with code in it, and being able to just backtick away into a tag or a

 block would be a godsend.

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?

We did indeed write A LOT of tests!

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.

Hi, thanks for this amazing work.

Just curious: Google docs supports a lot more than what Markdown has syntaxes for - how do you deal with this when exporting to markdown?

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

Thanks!

Google Colab also supports Markdown input cells as "Text" with a preview.

Does this work with Google Sites?

How to create a Google Sites page from a Markdown doc, with MyST Markdown YAML front matter

NotebookLM can generate Python, LaTeX, and Markdown.

How to Markdown and Git diff on a Chromebook without containers or Inspect Element because [...]

How to auto-grade Jupyter Notebooks with Markdown prose, with OtterGrader

How to build a jupyter-book from .rst, MyST Markdown .md, and .ipynb jupyter/nbformat notebooks containing MyST Markdown

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.

No support for code blocks still:

    ```java
    String x = "xxx";
    ```

No quoting:

    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.

Ah thank you. Too bad.

Funny that they paywalled that feature, while tools like Colab are free.

Generally, Google has made code-related and academia-related tools freely available. Oh well.

We just have to iterate in the "markdown support feedback/help" pulldown I guess. because without ```code``` it's not useful.

Looking at you HN... (ok at least we have 2 indents codeblock)

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.

They meant here on HackerNews. The only thing I really miss sometimes is a way to quote without resorting to indented code blocks.

> Just a tiny hint that any paragraph like this starting with a greater-than sign is a quote.

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 `

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

My guess is that this is strongly motivated by the success of LLMs.

The lack of MD support makes manual IO from Docs to your favorite LLM lossy (or very annoying). Cool that it's fixed.

Great job!

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!

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.

You can already get most of the way there, as Pandoc supports reading the ODT or DOCX export from Google Docs reasonably well.

I have this in my shell history:

  pandoc --from=docx --to=asciidoc --wrap=none --atx-headers --extract-media=img doc.docx > doc.adoc

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.

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.

Sorry, I was talking about scientific writing, where you have to be able to produce PDF artefacts.

Writing in markdown and converting to .tex is actually a quite popular way of doing that these days.

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

Indeed, very useful to unite markdown with the omnipresence of gdocs.

One tip for pasting without formating, at least in Windows, is CTRL+SHIFT+V.

Does this just import Markdowns and convert them to Gdoc and then you export it finally. Or can you collaborate on Markdowns in real time?

Could you build a confluence/wiki like system on top of this?

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 a cool feature, even if parts of markdown still need to be implemented (for pedants: commonmark).

Meanwhile, Trello is once again threatening to force everyone onto the new rich-text editor and disable the old markdown one.

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

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.

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

[0] We write about it briefly in a case study about "The Google Wiki" at https://abseil.io/resources/swe-book/html/ch10.html

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.

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.

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.

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.

look forward to trying this.

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.

when did google become sooo sloooow implementing trivial features, and then not even shipping a complete set of markdown?!

> trivial features

Four features were announced:

1. Convert Markdown to Docs content on paste

2. Copy Docs content as Markdown

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.

Notion is one of the best things that happened to Google Docs. It creates competition and Google Docs has get better since.

Even though Notion is now better on many fronts as you said, people who have to stick to Google Docs benefit from Notion's existence in that way.

（评论） (comments)

（评论）
(comments)