before i can replace vscode with zed

[HeavySnowJakarta]

i enjoy zed's speed and memory occupation, but before i could give up vscode...

• rainbow brackets
• rainbow indents
• enough language servers
• TODO highlighting support (even better with custom background color and somewhere to show the TODO tree)
• print and image generating
• enhanced markdown
  • full GFM grammar support
    • TODO lists
    • tables
    • strikethrough
    • emoji marks
    • footnotes
    • definition lists
  • chart painting
    • mermaid images
    • vega-lite
    • js-sequence
    • flowchart.js
    • echarts
  • export to PDF, HTML, etc
  • custom CSS
• non markdown docs
  • typst
  • others like latex, ascii docs, etc
• debug support
• code runner
• remote support
  • remote Git repositories (especially GitHub) for viewing codes locallly and small PRs
  • SSH servers
  • if possible, mosh
  • WSL
• do Git operations (like switching branches and do commits) with Zed, not only showing diffs

[solvworx]

My list is a lot shorter (because I use JetBrains tools for most of my dev work instead of vscode).

• print like vsc-print
• markdown export to PDF like vscode-markdown-pdf

Does anyone have a workaround for printing from zed?

[athyfr]

I would recommend using a CLI such as pandoc.

You can use the (relatively new) Zed tasks system to be able to access it from GUI, and if you want to customize the PDF styling (if you don't like the defaults,) you might draw inspiration from this guide.

Alternatively, if you want to keep using what you've already been using (under the hood), you could look for a CLI equivalent of vscode-markdown-pdf. You might have better luck with Pandoc, though.

I realize that this isn't the same as first-party support by Zed, but I'd personally prefer more user-customized interfaces like this over that first-party support, as that gives more features faster (because of Zed's limited workforce), potentially at the same or better quality.

[nickheyer]

My list is more-so a list of "why was this done like this it makes no sense":

An extension "store" that isn't comprised of 99% themes for the ui.

Also a git panel, I actually dont understand how this wasn't included before the AI integration.

Don't install AI "features" by default, do you know how many compliance standards you break by doing that?

Why is there a public chat room panel? Do you intend to provide a teams chat interface or a code editor? If it's intended to be used as a collaboration tool between team members, why in the world would you throw users into a public chat by default? It's now not clear to users that its intended to be used with your team, instead it makes your editor seem insecure to use with a proprietary code base.

It feels like zed was designed by project managers and tech youtubers. Calls itself minimalist, yet it takes the least minimalist features from the hat and calls it a day.

[HeavySnowJakarta]

About the extension apis we can see that extension api built-in with zed is much limited. For VS code, every element is considered as DOM objects (I've never understood VS Code's source and I really hope it was right). And we revise them as if we are operating HTML objects. Thus we can do almost anything with vs code. You can even add a clock or a live2d character on the panel. GPUI is brand new and with Rust and I thought there are really a lot to do for that. For now, many functions that actually can be done with extensions have to be built-in.

AI is good but I don't understand that why so many models are buillt-in which can just be done by installing extensions. Even OpenAI-compatible providers cannot be ported with Zed easily, but OpenAI, Anthropic and Google's apis are available out of the box. Deepseek model itself is good but only the official API is built-in while multiple providers are not really available which really does not make sense. Many providers' API is actually compatible with OpenAI, but we cannot use them just because we cannot set the url. So I think the design may be not as proper as it should be.

About chat rooms, it is a key feature of Zed. What I expect is that Zed should open the server's source and allow the user to build self-hosted service. Be relaxed that Zed is more like a solution of coding, rather than just an editor.

[aRustyDev]

@HeavySnowJakarta I see that you're hoping to get MoSH implemented into the remote development options for Zed.
I just started a discussion of why it would be useful and how we could go about implementing it here

If thats still something that interests you it would be helpful with getting traction to add a like to the discussion.

[JonGretar]

TODO comment highlighting is done by the comment extension. For it to work the parent language has to define comments as an injectable language but more and more are doing that.

For typst support I assume you are referring to live preview. Instead of the on-save preview that is currently implemented in the zed plugin?

We can debate back or forth if users should have access to the zed collaboration channel. Or if it should be empty list to begin with. But I want to point out that you are not "signed in" to these channels. You just can join them or create your own organization collaboration channel. The collaboration feature is the business plan and how they will in the end have an income. It's very basic now and only includes voice chat and project/screen sharing but once the editor itself is more stable you will see much more collaborative programming features.

[HeavySnowJakarta]

I'm not very sure about the implemented on-save preview, how shall I enable it? Also it will be even better to have the live preview. In vscode once we can preview markdown, we may preview everything, as everything previewed is just plain HTML. Maybe it's a little more to do for Zed to provide the document model to preview for extensions?

I agree with the idea that the collaboration channel may be discussed more later, at somewhere else. It's not a big thing, but it will be better if It can fit everyone's needs.

Gonna see the comment extension later

[JonGretar]

There was apparently a way to export on-type. And now a way to enable the server.

If you put this in your settings to make the LSP render the PDF on type it will re-render the output PDF on each keystroke.
This will require a bit better PDF reader that handles fast updates without flickering. I use sioyek for that.

For other PDF readers, like Skim, it's probably better to set this value to onSave. Otherwise the PDF will kinda flicker on the redraw as it re-reads the file. Ok on save, annoying on-type.

The other method is to use the preview server. This is like what VSCode does. Basically it's a web server that renders the document as a SVG. It's quicker but like in VSCode there is a potential issue of the preview having slight differences to the exported PDF. You would then open http://127.0.0.1:23635/ in a browser that you split-screen with Zed.

If you wish to use the web-server method I would have the PDF export set to onSave.

  "lsp": {
    "tinymist": {
      "settings": {
        "exportPdf": "onType",           // or onSave
        "outputPath": "$root/target/$dir/$name"
      },
      "initialization_options": {
        "preview": {
          "background": {
            "enabled": true
          }
        }
      }
    },
  }

[HeavySnowJakarta]

well maybe a more generic way of rendering docs within zed seems to be better. now the built-in preview couples with markdown

[JonGretar]

well maybe a more generic way of rendering docs within zed seems to be better. now the built-in preview couples with markdown

In VSCode as well I had switched to using an external viewer for the typst preview. It's just more flexible.

[HeavySnowJakarta]

In VSCode as well I had switched to using an external viewer for the typst preview. It's just more flexible.

now i agree with you. but sioyek doesn't fit very well, it even does not have a scroll bar, and it's too slow to navigate among the pages with the mouse scroll wheel. is there any other instant real-time pdf viewer?