The principal focus of the next batch of work is turning xi-mac into a viable (albeit minimal) editor for daily use. To that end, the following is what I anticipate working on for the next 3-6 months:
Major Goals
Width measurement and word wrap (overview/tracking at #565):
minimal language features
I've been avoiding this because doing it 'correctly' (in my estimation) involves confronting a bunch of fundamental problems about how languages are defined, the role of plugins, etc. But I'd like to be working in xi day-to-day, and the main things that bother me right now are comment toggling and manual indentation, so doing a 'good enough' implementation of this, for now, makes sense. In any case, there are two obvious approaches here; the first is to get this working through syntect metadata, and the other is to add something simple through the config system similar to what vscode does.
misc other projects
There are a number of projects currently being worked on by other contributors:
As well as a number of projects related to the mac client, which are out of scope here.
Getting involved
If you're interested in hacking on xi-editor, feel free to browse the issues. If you're interested in taking on something deeper, there are a number of open-ended questions and projects that could be interesting to explore:
Alternate syntax parsers (highlighters)
In xi-editor, syntax highlighting is provided by plugins. Currently there's only one such plugin, based on syntect. It would be fun to experiment with others. There are two good projects here: one is the currently broken plugin in /experimental/lang (#925), and the other would be writing a new plugin that uses tree-sitter (#753). Either of these projects would help expose any limitations of our current approach, and help us think about how best to implement full multi-plugin support.
Displaying errors, lints, and compiler output (needs issue)
This is a medium sized project that isn't really on the immediate roadmap, but would be a fun exercise for someone interested in diving a bit more deeply into xi. It would involve (probably) changes to the update protocol, as well as work in core and in the client, but it is also self-contained and can be hacked on without significantly overlapping with other work.
Toy autocorrect
This summer, @betterclever @nangtrongvuon and myself spent a bunch of time playing around with various integrations related to the Language Server Protocol. We learned a lot through that work, but I'd like to try and step back and look at language support features one by one. Autocorrect is a good place to start. I've sketched out what this would look like in #774, but I won't be revisiting this for a while; if someone wanted to take that up and try to play around with a simple autocomplete system that completes symbols in the current file, that would be a good place to start.
Performance metrics and regression tracking
At some point we will want to start more aggressively measuring and tracking performance. This is a vague, open-ended problem; but ideally we would have something like a CI system for performance, that would let us run some set of real-world benchmarks against new commits, and allow us to visualize changes over time. A good first step for this would be to create a new xi-bench crate that starts putting together these sorts of real-world benchmarks.
The principal focus of the next batch of work is turning xi-mac into a viable (albeit minimal) editor for daily use. To that end, the following is what I anticipate working on for the next 3-6 months:
Major Goals
Width measurement and word wrap (overview/tracking at #565):
minimal language features
I've been avoiding this because doing it 'correctly' (in my estimation) involves confronting a bunch of fundamental problems about how languages are defined, the role of plugins, etc. But I'd like to be working in xi day-to-day, and the main things that bother me right now are comment toggling and manual indentation, so doing a 'good enough' implementation of this, for now, makes sense. In any case, there are two obvious approaches here; the first is to get this working through syntect metadata, and the other is to add something simple through the config system similar to what vscode does.
misc other projects
There are a number of projects currently being worked on by other contributors:
As well as a number of projects related to the mac client, which are out of scope here.
Getting involved
If you're interested in hacking on xi-editor, feel free to browse the issues. If you're interested in taking on something deeper, there are a number of open-ended questions and projects that could be interesting to explore:
Alternate syntax parsers (highlighters)
In xi-editor, syntax highlighting is provided by plugins. Currently there's only one such plugin, based on syntect. It would be fun to experiment with others. There are two good projects here: one is the currently broken plugin in /experimental/lang (#925), and the other would be writing a new plugin that uses tree-sitter (#753). Either of these projects would help expose any limitations of our current approach, and help us think about how best to implement full multi-plugin support.
Displaying errors, lints, and compiler output (needs issue)
This is a medium sized project that isn't really on the immediate roadmap, but would be a fun exercise for someone interested in diving a bit more deeply into xi. It would involve (probably) changes to the update protocol, as well as work in core and in the client, but it is also self-contained and can be hacked on without significantly overlapping with other work.
Toy autocorrect
This summer, @betterclever @nangtrongvuon and myself spent a bunch of time playing around with various integrations related to the Language Server Protocol. We learned a lot through that work, but I'd like to try and step back and look at language support features one by one. Autocorrect is a good place to start. I've sketched out what this would look like in #774, but I won't be revisiting this for a while; if someone wanted to take that up and try to play around with a simple autocomplete system that completes symbols in the current file, that would be a good place to start.
Performance metrics and regression tracking
At some point we will want to start more aggressively measuring and tracking performance. This is a vague, open-ended problem; but ideally we would have something like a CI system for performance, that would let us run some set of real-world benchmarks against new commits, and allow us to visualize changes over time. A good first step for this would be to create a new xi-bench crate that starts putting together these sorts of real-world benchmarks.