Context Servers supporting multiple output sections

[jshph]

Check for existing issues

• [X] Completed

Describe the feature

It's really great to see support for context servers -- I've been learning from reading @dsp-ant 's PR and @jvmncs 's work on python-context-server. Are there any plans to allow for multiple output sections in the protocol? I am reading the file_command implementation and appreciate the behavior that when I enter a folder, it creates a section for each file in that folder. This is nice because it gives the ability to remove files at a high level in the assistant context view:

I am new to Rust and have developed a plugin for Obsidian; I am considering two routes:

• Re-implementing the context server at the LSP level in Rust (good learning experience, longer path to parity with Obsidian, perhaps more performant in the long run)
• Implementing an API in Typescript in the plugin that would allow it to serve as a context server for Zed (get to use the Obsidian API; there is file extraction logic here that is fairly intricate)

My best option, if I understand correctly, is to format the entire contents (which may span several files) which to pass back through the context server protocol in Zed. Hoping for some guidance here, thanks!

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[dsp-ant]

Hi @jshph,

thanks for the interest in Context Servers. I think your usecase makes a ton of sense. let me dig into the different parts of your request:

Sections

You are right, Context Servers currently don't have a notion of sections and it would be quite useful to have that. I want to think through your use case and see how we can best natively support this in the protocol. In the meantime, a potential workaround is that you can return /file <filename>. Zed will take care of it and treat it as a slash command that then can get executed if the user wishes and would return you a section. So just return a list of /file <path> delimited by newline might be a good first step.

A protocol change, if happens, would likely take 1-2 weeks to land, assuming we want to do that. Let me think about it and then get back to you. I certainly think it's a valid problem and necessary restriction for now.

Extensions vs Context Servers

I wouldn't worry too much about performance. The interactions will be fast enough either way since we aren't in a low-latency context. My mental model for extension vs Context Servers is that extensions will longterm allow you more flexibility and deeper integration into Zed, while Context servers might allow you to faster prototype, give you easy access to libraries in a target language you might like, and potentially be more reusable. It really comes down to what you like. A potential start is to try context servers and once you hit limitations rewrite as extension. Note however, we are at the moment still changing the protocol quite a bit and there is just not yet a up-to-date library anwhere . That being said, I expect us to stabelize quite soon and the protocol is easy enough to have Claude or GPT write you a server in no time :).

Hope that helps.

[jshph]

Hey David, appreciate the thoughtful response! I'm hoping to rely on more nuanced file retrieval than /file -- the gist is to retrieve all files that mention #tags or [[wikilink style entities]], via slash command. A section can be defined in a few different ways here, but just a couple of examples: one per <mention, file> pair (where the extraction method would furnish the contents before and after the mention), or perhaps one per file (with concatenated mentions). I think you're right that a context server would be the most straightforward way to prototype that for the time being. It may be up to the context server to provide a list of sections in its response, and rely on Zed to assemble it all.

I'll be tinkering with this in the coming days, so let me know if I can provide some examples to work with or test out on your end!