November 2017 Roadmap
raphlinus opened this issue · 8 comments
Xi was first launched in April 2016, as a promising prototype but not an editor suitable for daily work. Work since then has included essential features and also infrastructure, particularly the CRDT that supports asynchrony from plugins, and a working demo of multi-device editing on Fuchsia. In my experience, it is now close to a good basic editing experience, but not quite there. The main focus of the next few months is to push it over the line.
Performance
Much of the promise of xi is very high performance. It is currently not delivering on that promise, and in fact it has regressed in some ways. A major focus is to fix these performance problems.
- Minimal invalidation - just repaint what's changed, as opposed to the whole screen. This requires changes spanning core and front-end. The current core to front-end update protocol is designed to handle this, just needs better implementation. (#317, PR #445)
- Flash of content on scrolling. The best fix for this is to reintroduce the synchronous "get_lines" RPC; trying to do it entirely async adds to overall complexity. (xi-editor/xi-mac#89)
- Short timeout for aggregating updates from plugins (particularly syntax highlighting). This will prevent flash of uncolored text. (#267)
- Performance measurement infrastructure - will help prevent future regressions. (#478)
- Probably out of scope but planned for future: async loading of very large files (especially useful for file viewing use case). (#197)
Coding essentials
Raph used xi as his main editor during his sabbatical at Recurse Center and found it mostly usable but with a couple of pain points.
- Auto-indent. TextMate/Sublime syntax definitions include info to drive an auto-indent feature, so ideally syntect would grow the ability to process these. If that will take time, the syntect plugin could use an extremely simple heuristic (same indent level as last line with a delta for { or } as the last character on the line). The plugin interface currently supports the basic functionality for a plugin to edit the text, but will need some refinement (plugin edit in the same undo group as the manual edit, finer granularity in the multi-selection case). (#424)
- Reload on file change. This has been one of my biggest pain points, as doing a git checkout followed by a save clobbers the checkout. (#362, PR #538)
As xi develops, as much IDE-like functionality as possible will be implemented in plugins. There's a lot of functionality to be exposed (for example, navigating between files, including opening new ones). Over the next few months, I expect to be prototyping some of this, but it's not an immediate goal.
Fuchsia
One of the main use cases for xi is editing general purpose text on Fuchsia (for example, for email composition). Goals for the next few months include:
- Make the Fuchsia front-end more fully featured and performant.
- Word wrap. This will require a solution to measuring the width of text (generally this will not be a monospace font). (#184)
- The beginnings of rich text.
References
- Previous roadmap (May 2017): #252
@raphlinus I'm not sure you haven't considered that but making scrolling async is actually very easy. You just need to embrace it and be explicit about it. So you can just do what they do in tweets feed etc where the content could be too large to actually load and show to the user - show some spinning thing while loading new content.
@purpleP While that is certainly an option, our goal is to have the async stuff not be explicit; the user should not need to know or understand what's happening behind the scenes, and I think a loading wheel in a text editor would be pretty tough to swallow.
@cmyr Well, if the file is big can loading take perceivably long with algorithms you use or planning to use? And if that's the case showing the wheel is the best option isn't it? You're not planning for the editor just to hang in this case, are you?
@purpleP Async read for large files (#197) is an eventual goal, and in that case some UI indicator that a read is in progress might be useful.
What we're talking about here is the case where we have a document already in memory, and we're just painting lines; and we would like to not miss frames, even when the frontend has to request lines from the backend, which may not have computed style information etc.
Any idea if basic word completion functionality will be added?
@AHL96 autocomplete is not on the immediate roadmap, but would probably make the subsequent one (summer 2018?)
Why is Auto-indent still unimplemented ?
There actually is an implementation of it already, but it's disabled in the default config because it apparently has some problems. An improved version is currently being worked on.