Repository navigation
👀 Editor View #36
Description
Activity
- Reacted by Austin Condiff
I've spoken to the developer of CodeEditorView and added mchakravarty/CodeEditorView#43 and mchakravarty/CodeEditorView#44. I also left some comments on mchakravarty/CodeEditorView#3.
- linked a pull request that will close this issuefeat: added code editor #50
on Mar 18, 2022 Let's reopen because this editor is just a start. I assume based on PR comments that it will not support #46 among other things like diff, code completion, messages, validation, etc. all of which are being worked on or supported by https://github.com/mchakravarty/CodeEditorView.
I'm actively working on a custom solution built over Highlightr.js!
Reacted by Lukas Pistrol and Austin Condiff@MarcoCarnevali Hello! It looks like you've already found something you want to use, but I thought I'd let you know what we're up to just in case.
My app (Chime) does highlighting (and indentation) using tree-sitter. We've open sourced a low-level library for working with it in Swift.
However, Chime has a huge amount of infrastructure on top of that for its actual implementation. We were actually in the process of pulling out another layer in the system now. A few others have asked about this before, so it was something we wanted to do anyways.
If any of this sounds interesting, let me know and we can discuss more!
Reacted by Ilya Rodionov, SweetPPro and Freya Alminde@mattmassicotte I'm currently using a wrapper around highlightjs but happy to change it to something better! I would definitely love to discuss more on that, seems interesting!
I'm not familiar with highlight.js, but it looks like a great tool!
I've taken many different paths along my syntax highlighting journey. Right now, Chime uses a hybrid tree-sitter + LSP semantic tokens.
Tree-sitter's support for incremental parsing gives it really good performance characteristics. However, Chime has to wrap it up with a bunch of extra stuff to make it both lazy (only coloring what the user sees) and asynchronous (computing coloring in the background, if needed). Plus, it supports generalized syntax-tree queries, which we use for structure highlighting (matching
if-{-}) and precise indentation calculations. Tree-sitter is awesome, but very complex.LSP also has a syntax highlighting system called semantic tokens. Glueing together both of these is tricky. But, it's desirable because semantic tokens can provide better information, but is slower and always asynchronous. Tree-sitter isn't as precise, but is faster and can be used synchronously if needed. It also works well in the face of syntax errors, which is the common case during editing.
I was just in the process of pulling out some more of the tree sitter system we use, it will be here: TreeSitterClient . But, I'll need some more time to finish that. And, even when done, that's just perf/convenience around the system, not a full highlighting implementation...
Reacted by Ilya Rodionov- changed the title
[-]Use Editor View instead of a simple Text View[/-][+][FEAT] - Use Editor View instead of a simple Text View[/+]on Mar 21, 2022 That's definitely something we need, the current system it's not really scalable and good performances wise. What do you think would the timeline be like?
Pulling out stuff like this is always a little easier said that done, haha. I'm making progress, but I have some higher-priority stuff going on this week. I'm hoping by next week!
However, I do want to stress that this is not a drop-in highlighting library. It just makes it much easier to connect a text storage system (like one backed by
NSTextStorage) to tree-sitter in a performant way. The incremental stuff will just work, and could be helpful right from the beginning. But, background processing is necessary for low-latency with large documents. That is much more complex, and requires maintaining a stable and thread-safe view of your text across user edits. I do this a few different ways, butBufferingTextStoragefrom TextStory may be interesting here.Progressive highlighting (multiple passes of varying latency/quality) also really helps for performance and user perception, but is an entirely different thing.
Do you have any highlighting performance/quality targets for your first release?
18 remaining items
I got interested, so I played around with SPM-izing tree-sitter directly. I was inspired by how Simon did it with Runestone. Note that tree-sitter produces some warnings during its build, so these spill over to the project when used via SPM. This should be fixable, but I haven't yet investigated.
I was also able to do this for a single parser. But that should be enough of a proof-of-concept that it can be done for all of them. I don't have anything public for this yet.
Here's the fork of tree-sitter that supports SPM directly:
https://github.com/mattmassicotte/tree-sitter/tree/feature/swift-packageAnd here's the fork of SwiftTreeSitter that depends on it, and not on a pre-built binary:
https://github.com/ChimeHQ/SwiftTreeSitter/tree/feature/no-xcframeworkSo, this is a complete built-from-source tree-sitter library. And, it should now be possible to select languages as desired, and just include them as SPM dependencies. I think I like this approach better, so I'm going to start moving towards this.
But, you should absolutely feel ok deciding to take control whichever parts you need to. This is your project and you need to proceed in the way that makes the most sense.
Reacted by Austin Condiff, Lukas Pistrol, Lingxi Li, Ilya Rodionov and WauaReacted by Lukas Pistrol and Lingxi LiThanks a lot @mattmassicotte! This is great! With this in mind, do we want to follow a similar path for our editor @lukepistrol?
Basic implementation of
tree-sitterusingSwiftTreeSitterandSTTextViewis now available onfeature/new-editorbranch.Contributions are welcome on the editor package
CodeEditTextView! Documentation is available here.Thanks to @mattmassicotte for creating
SwiftTreeSitterand for helping me with questions.
Also big thanks to Marcin Krzyzanowski for creatingSTTextViewas an alternative toNSTextView.Note that
STTextViewis still in active development and if some features are missing you might consider contributing there as well.Reacted by Ilya Rodionov@s0me0ne-coder Those two don't really pertain to the editor view itself.
Closing because we have mostly implemented this
- added a commit that references this issue
on Sep 7, 2024
Metadata
Metadata
Type
Projects
- Status
Note
The Editor View lives in
CodeEditSourceEditorand features a basic implementation oftree-sitterusingSwiftTreeSitter.Overview
We need to implement a fully featured editor view. This view sits inside the Workspace UI (#346). We need to determine if we should roll our own
or use an existing solution.Features
Our code editor view should include the following features
Resources
Packages to considerCodeEditorViewCodeViewerCodeEditorSourcefulSavannaKitCotEditor