ChimeKit provides the functionality needed to build extensions for Chime, the editor for macOS. You can use it to provide semantic features, display views, and integrate with ExtensionKit. Chime can do a lot more with extensions.
Chime's extensions are based on ExtensionKit. They are written in Swift and SwiftUI. ChimeKit also includes a system for integrating Language Server Protocol servers with the extension API. For the most part, ChimeKit abstracts away all of the ExtensionKit details. You program against the ChimeKit APIs, not the ExtensionKit primitives. However, ExtensionKit does impose some requirements related to security and distribution you must be aware of.
ChimeKit development requires Chime 2.0, Xcode 14, and macOS Ventura (13.0). However, extensions should try to match ChimeKit's macOS Monterey (12.0) requirement.
📖 Documentation is available in DocC format. But, please don't be shy to reach out to us - we'll help!
ChimeKit supports different integration options, all available via SPM. Be sure to read more in the documentation, as it isn't as straightforward as a typical SPM package.
dependencies: [
.package(url: "https://github.com/ChimeHQ/ChimeKit", branch: "main")
]We want to provide a simple user experience for extensions, particularly for language support. We don't think it's great to have four different extensions for one language. So, while we will not gatekeep, we'll have a very strong bias towards one extension per language.
LSP is pervasive in language support extensions. Many IDEs use a model of one extension per language server. ChimeKit allows for multiple servers per extension. We think of LSP servers as an implementation detail of language support. Coordinating the behaviors of multiple servers is the job of an extension, not the user.
All of Chime's extensions are open source and we will always begin work on new language support as open source projects.
I would love to hear from you! Issues or pull requests work great. A Discord server is also available for live help, but I have a strong bias towards answering in the form of documentation.
I prefer collaboration, and would love to find ways to work together if you have a similar project.
I prefer indentation with tabs for improved accessibility. But, I'd rather you use the system you want and make a PR than hesitate because of whitespace.
By participating in this project you agree to abide by the Contributor Code of Conduct.