-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Syntax highlighting #436
Comments
I considered something similar in #238 (switching from a vanilla Did you have some simpler approach in mind? I'm not an expert, but I thought adding any sort of highlighting would require completely replacing the textarea with something else (and that is tricky to do well, especially across different operating systems). |
I think it's possible to make a highlighted editable textarea using some technique like in https://css-tricks.com/creating-an-editable-textarea-that-supports-syntax-highlighted-code/ . As for parsing the SIC-1 code, since SIC-1 is line-based, parsing the inserted/deleted code onchange incrementally might be a feasible and efficient approach. I will try to work on this recently when available. |
Hmmm... that demo doesn't work well in Firefox (new lines seem to confuse it), but I haven't looked into why. I guess I'm kind of skeptical that approach would work out well, but I haven't investigated it in depth. |
Looks like it's due to |
Ok, finally found a moment to answer your original question: would I accept a PR for this? There are a couple of concerns:
The first one is something I need to think about. The second one worries me, but doesn't seem insurmountable (although I'm not sure how to test on Safari since I don't own any macOS devices). The last one seems tractable. Side note: I noticed a small issue with that demo in Chrome: if the text is long enough to require a scrollbar, then hitting the home/end keys doesn't scroll far enough to reveal the caret--I originally thought the caret had disappeared. |
Alright, I think these concerns are reasonable. By the way, what about making syntax highlighting an opt-in feature? We can use the original textarea by default, and provide an option to turn on syntax highlighting. In this way, most users won't be affected by the potential defects of the new editor, and those who want syntax highlighting can enjoy the new feature whilst take the risk of facing bugs/imperfect styles. The syntax highlighed editor may still be implemented using vanilla Javascript to keep light-weight and simple, and we can gradually improve it by addressing reported issues. |
With respect to concern 1 in my previous comment:
I haven't actually updated the license yet, but I've decided (for sure) on open-sourcing the code: #458 |
My eyes hurt every time reading the monochromic list of code. Do you think it's a good idea to add syntax highlighting to the editor? If so, I would file a PR for this.
The text was updated successfully, but these errors were encountered: