21–30 of 306 posts
That solves a lot of the Emacs trouble iiuc. (Same for the Async first design).
> The xi editor will communicate with plugins through pipes, letting them be written in any language,
That's caused a lot of trouble for vi/vim, has it not? I get the separation of concerns, but intermingling the concerns has helped emacs in a certain way.
Xi looks great, has a very clever design, and clearly is a next generation platform for building a useful and powerful editor. I'd love to see this project continue and be a success. I think there is plenty of room for yet another text editor. Here's where I'm going to be a bit of a party pooper. Pragmatically speaking all of the great stuff Raph is talking about doesn't really matter. What Raph cares about are the k…
You named some random things that have been around for short periods of time and claimed that "they won". I don't get it.
The momentum there eclipses... Eclipse, as well as many other closed and open source editors.
If you don't see the Electron ecosystem as a winner today would you say they'll have won if all editors stay at their current momentum of new features and bug fixes?
Presenter here, feel free to ask questions. Also thanks to the awesome Recurse Center for inviting me to speak and making the recording, and the audience for their great questions.
Presenter here, feel free to ask questions. Also thanks to the awesome Recurse Center for inviting me to speak and making the recording, and the audience for their great questions.
Do you think the language used will last for 20 years in terms of developer interest?
Xi 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
Xi 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…
Earlier quoted context omitted.
You named some random things that have been around for short periods of time and claimed that "they won". I don't get it.
Based upon momentum I believe the Electron based ecosystem has already won, yes. The momentum there eclipses... Eclipse, as well as many other closed and open source editors. If you don't see the Electron ecosystem as a winner today would you say they'll have won if all editors stay at their current momentum of new features and bug fixes?
That’s where Xi fits. It’s saying “these things we don’t get from other editors are important”. Users are free to decide which feature or attributes are most important to them. At the end of the day, users win!
Xi 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…
A more interesting approach would be to use persistent data structures. While possibly slower for some operations, undo is more efficient and there are really interesting opportunities for concurrency. See: https://github.com/arximboldi/ewig/blob/master/README.md
Presenter here, feel free to ask questions. Also thanks to the awesome Recurse Center for inviting me to speak and making the recording, and the audience for their great questions.
I wonder, in the talk you say that you took some ideas from the design of Chrome; do you think that --in turn-- browsers could learn from the concepts in Xi?
And another question: you are using multiple languages. Doesn't that make it needlessly difficult to express the same operations in different (concurrent) parts of the system? E.g. a character update is rendered on the screen (in Swift), and simultaneously the operation is sent to the core (in Rust) to reconcile the change in the core data structures; both operations are essentially the same, but now they have to be written in a different language, which means more development work and increased likelihood of mistakes/inconsistencies (?)
PS: I'm not sure if this makes sense; I couldn't finish watching the talk but will watch the rest later!
Xi looks great, has a very clever design, and clearly is a next generation platform for building a useful and powerful editor. I'd love to see this project continue and be a success. I think there is plenty of room for yet another text editor. Here's where I'm going to be a bit of a party pooper. Pragmatically speaking all of the great stuff Raph is talking about doesn't really matter. What Raph cares about are the k…
But for extremely large files, I use EditPad Lite.