Xi: an editor for the next 20 years [video]
recurse.com
Xi: an editor for the next 20 years [video]
1–10 of 306 posts
Re: Xi: an editor for the next 20 years [video]
#2There finally starts to be consciousness about input and output latency for GUI applications.
Xi sounds like an editor I'd love to use. Latency while typing is a jarring experience.
Re: Xi: an editor for the next 20 years [video]
#3I'm glad `xi` is separating the editor core from the UI.
This feels more correct. So the GUI authors can work on the chrome and polish, while the editor team focus on performance and all the nitty-gritty memory operations.
Re: Xi: an editor for the next 20 years [video]
#4VI(m) has been around for a long time now....
Re: Xi: an editor for the next 20 years [video]
#5There finally starts to be consciousness about input and output latency for GUI applications. Xi sounds like an editor I'd love to use. Latency while typing is a jarring experience.
You might be interested in this article from a JetBrains developer who implemented zero-latency typing in IDEA:
Re: Xi: an editor for the next 20 years [video]
#6Async and CRDT to coordinate between core and plugins is super clever and seems scalable to future design choices. Levien calls out that there is a high complexity overhead to this architecture, but that it's probably worth it to maintain performance.
Re: Xi: an editor for the next 20 years [video]
#7There finally starts to be consciousness about input and output latency for GUI applications. Xi sounds like an editor I'd love to use. Latency while typing is a jarring experience.
Xi backend repo: https://github.com/google/xi-editor
Fuschia front-end client for Xi: https://fuchsia.googlesource.com/topaz/+/master/app/xi/
Re: Xi: an editor for the next 20 years [video]
#8There finally starts to be consciousness about input and output latency for GUI applications. Xi sounds like an editor I'd love to use. Latency while typing is a jarring experience.
People used to put a lot of effort into minimizing latencies. In large because they had to. However, you almost always land in an effectively cooperatively multitasking environment if you want truly lightning fast latency. Just after that, you are just reimplmenting schedulers and other preemptive tools. All of which just gives a hot target to a few particularly scheduled jobs that every developer feels their stuff has to happen in.
Re: Xi: an editor for the next 20 years [video]
#9Xi creator did an amazing work implementing ropes (https://github.com/google/xi-editor/tree/master/rust/rope)
The design documents (https://github.com/google/xi-editor/tree/master/doc/rope_sci...) explaining the concepts and implementation details is a must for those who want to understand its core.
But I still have my regards regarding input latency being accredited only to the text editor. I recently switched back to Linux (nvim running on alacritty with tmux) and the latency issues magically disapeared. During my iterm2 (and even terminal) period on OSX I felt horrible lag during operations which I don't even have time to blink with my current setup.
The last straw was once I found out iterm2 consuming 10% of my CPU in idle, the issue only happened when any non builtin font (menlo, monaco or courier) was used.
Re: Xi: an editor for the next 20 years [video]
#10Xi creator did an amazing work implementing ropes ( https://github.com/google/xi-editor/tree/master/rust/rope ) The design documents ( https://github.com/google/xi-editor/tree/master/doc/rope_sci... ) explaining the concepts and implementation details is a must for those who want to understand its core. But I still have my regards regarding input latency being accredited only to the text editor. I recently switched b…
Have you tried using Alacritty? https://github.com/jwilm/alacritty