You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It takes a few seconds to open files once clicked (See #20). Before fixing this, let's take this opportunity to handle large files that may take a while to load.
If the file takes a while to open, the UI should respond to the users action immediately, otherwise they will think the app is frozen/broken.
I'd recommend opening an empty tab with a label of filename from the file tree in the sidebar. Then we would display a loading spinner in place of the icon. If hovered the loading spinner is replaced with a close icon button to close the tab if it is taking too long. Either that or simply display a loading spinner in the center of the content area.
Once loading is complete, the file contents are displayed.
This way the UI is responsive to user action and it will not feel as laggy or broken.
These words may be very unpleasant, and I'm sorry I'm raising some doubts about the project here.
Building a native code editor is much difficult than you guys thought.
If you want to build a real code editor, not a prototype, write your own Swift native syntax parser and design your syntax definitions from the scratch. Highlightr uses highlight.js and JavaScriptCore as its core, it's not a native framework and it's buggy and slow.
It's not just as simple as creating a target - [] Syntax highlighting then integrate an existing project and put a x-mark on that like - [x] Syntax highlighting. It's ridiculous.
It's hard to imagine this project has 2.6k+ stars without conducting a valid evaluation before introducing the work of others. The feature Code symbols navigator also relies on a solid, native syntax parser.
Using SwiftUI as the major UI framework is also a bad idea. SwiftUI's vision is to lower the barrier to entry for iOS development and attract more developers. It's not suitable for a high-performance code editor.
Integrated terminal is another big challenge. Even Xcode does not have a good look terminal. I'm amazed that you have set too many goals that seem impossible in this project.
Developers that use a Mac shouldn't be forced to use an app from the other guys. Yes, these other editors have growing communities and infrastructure around extensions, and have seen incredible adoption that satisfies the needs of most developers. However, comparable editors are built on Electron. This is a huge limitation because it cannot utilize all system resources to it's fullest potential.
Review your project Motivation and think about yourselves. Don't criticize Visual Studio Code at will, because you don't know the difficulty of build a cross-platform, stable, and universal code editor.
Best references for you:
A modern and flexible regular expressions library Oniguruma
@Lessica We are well aware that this is not an easy task. The editor that uses Highlightr.js is just there temporarily while we get our own custom solution in place. We are not in any huge hurry. Our goal is to do this right. If you have any constructive feedback that is fine, but if you only have negative things to say then go find another project to bash. We are committed and determined to produce something developers on a Mac will enjoy. If you feel like we are doing something wrong, you are always welcome to contribute in order to make it right!
@lilingxi01 this issue will be fixed with the implementation of our new editor and file load times have been improved significantly since the time of issue creation. Thank you for pointing that out though, I think we leave this closed for the time being.
Activity
Lessica commentedon Mar 21, 2022
These words may be very unpleasant, and I'm sorry I'm raising some doubts about the project here.
Building a native code editor is much difficult than you guys thought.
If you want to build a real code editor, not a prototype, write your own Swift native syntax parser and design your syntax definitions from the scratch.
Highlightruseshighlight.jsandJavaScriptCoreas its core, it's not a native framework and it's buggy and slow.It's not just as simple as creating a target
- [] Syntax highlightingthen integrate an existing project and put a x-mark on that like- [x] Syntax highlighting. It's ridiculous.CodeEdit/README.md
Line 19 in 54184af
It's hard to imagine this project has 2.6k+ stars without conducting a valid evaluation before introducing the work of others. The feature
Code symbols navigatoralso relies on a solid, native syntax parser.Using SwiftUI as the major UI framework is also a bad idea. SwiftUI's vision is to lower the barrier to entry for iOS development and attract more developers. It's not suitable for a high-performance code editor.
Integrated terminalis another big challenge. Even Xcode does not have a good look terminal. I'm amazed that you have set too many goals that seem impossible in this project.Review your project
Motivationand think about yourselves. Don't criticizeVisual Studio Codeat will, because you don't know the difficulty of build a cross-platform, stable, and universal code editor.Best references for you:
[-]Handle long file load times[/-][+][BUG] - Handle long file load times[/+][-][BUG] - Handle long file load times[/-][+]🐞 Handle long file load times[/+]lilingxi01 commentedon Apr 20, 2022
Is this issue resolved? I think the issue being resolved is the folder hierarchy loading time, not the file opening time.
austincondiff commentedon Apr 20, 2022
@Lessica We are well aware that this is not an easy task. The editor that uses Highlightr.js is just there temporarily while we get our own custom solution in place. We are not in any huge hurry. Our goal is to do this right. If you have any constructive feedback that is fine, but if you only have negative things to say then go find another project to bash. We are committed and determined to produce something developers on a Mac will enjoy. If you feel like we are doing something wrong, you are always welcome to contribute in order to make it right!
@lilingxi01 this issue will be fixed with the implementation of our new editor and file load times have been improved significantly since the time of issue creation. Thank you for pointing that out though, I think we leave this closed for the time being.
Optionally Use System Cursor (CodeEditApp#21)