Xi-Editor Retrospective • Hacker News Board

Re: Xi-Editor Retrospective

#21

Post by pjmlp » Sat, Jun 27, 2020, 8:47 PM UTC

brunoqc wrote: post #4

sq_ wrote: post #3

Earlier quoted context omitted.

Atom already seems to have gone somewhat towards maintenance mode since Microsoft bought Github. Feels like there's a lot less by way of features being released and a lot more just keeping up with ecosystem/OS changes. I could certainly be wrong though.

Microsoft probably wants people to use vscode.

And given how Office loves React Native, and Microsoft is making it work across all major desktop OSes, with the team continuously bashing Electron's bloat on their talks, I look forward to the way when RN powers VSCode.

Re: Xi-Editor Retrospective

#22

Post by blub » Sat, Jun 27, 2020, 8:54 PM UTC

Am I the only one on HN which thought this was a bad idea all around from the beginning? I remember that people were very enthusiastic back then because of the Rust hype and the author's pedigree, so critics were quickly silenced.

For me, picking Rust and the JSON-based IPC were huge red flags and this post-mortem confirms that. But what I find odd is that many are still not willing to accept the conclusion that using Rust for a UI-intensive app is a bad idea. And using multiple languages in a project and splitting in back-end vs. front-end or lib + UI is also quite popular around here, unjustifiably in my opinion when one considers the extra complexity involved.

Re: Xi-Editor Retrospective

#23

Post by galonk » Sat, Jun 27, 2020, 9:02 PM UTC

saagarjha wrote: post #9

Aww, this is really disappointing to hear but an excellent read nonetheless. I always had Xi in the corner of my eye as a very interesting way to make a text editor that had a lot of good things going for it: modularity, native UI, speed…I think if it worked out it would have been really great. It's really sad to hear that it didn't. Thank you, Raph and the rest of the Xi contributors, for working on it for all these…

I want to echo this, it's disappointing, but I'm thankful to Raph and the team for all the work they put into it. I had dreams of being able to write an editor where I could concentrate on making a cool UI in a different language/framework and have Xi do all the hard stuff.

I think LSP will end up being the "good enough" solution for niche languages, while popular languages get dedicated IDEs/mega-plugins, a la the various language flavours of IDEA, XCode, etc.

Re: Xi-Editor Retrospective

#24

Post by GolDDranks » Sat, Jun 27, 2020, 9:10 PM UTC

blub wrote: post #22

Am I the only one on HN which thought this was a bad idea all around from the beginning? I remember that people were very enthusiastic back then because of the Rust hype and the author's pedigree, so critics were quickly silenced. For me, picking Rust and the JSON-based IPC were huge red flags and this post-mortem confirms that. But what I find odd is that many are still not willing to accept the conclusion that usin…

I was quite enthusiastic about it, and don't see even now why using Rust for a UI-intensive app would be a bad idea in general. If doing an app with a "monolithic" design, the lack of good frameworks is a problem, but that's improving, so it wouldn't be a good idea if you want to see results right now, but I'm pretty comfident that's gonna change.

However, I fail to see how the choice of Rust is relevant in this particular project, as the UI part was meant to be programmed in any language, making Rust an irrelevant part of the equation.

On another note, I'm baffled why you are downvoted. I find your comment negative, but not unreasonable.

Re: Xi-Editor Retrospective

#25

Post by cjohansson » Sat, Jun 27, 2020, 9:21 PM UTC

Front-end / interace needs to be synchronously controlled, it doesn’t feel right otherwise. I followed xi-editor but it never was faster than emacs on opening really large files and editing them so it never had a use case for me

Re: Xi-Editor Retrospective

#26

Post by CyberDildonics » Sat, Jun 27, 2020, 9:24 PM UTC

blondin wrote: post #2

had that feeling... as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea. that paradigm or at least the way we implement it might even mean more trouble than a synchronous counterpart. also, other editors that i feel will be sunset or not worked on at some point are atom and brackets.

I don't think you can blame this on an async design. Right off it talks about having the keyboard input as a separate process, not knowing what version of the buffer input should apply to, using timeouts and I guess, doing everything over local IP. It almost reads like a list of what not to do.

Why not put the input into the window, put a version number with the buffers and keyboard input and use shared memory? Of course something isn't going to work if you don't confront the problems you have at a fundamental level.

Re: Xi-Editor Retrospective

#27

Post by Matthias247 » Sat, Jun 27, 2020, 9:28 PM UTC

The_rationalist wrote: post #20

blondin wrote: post #2

had that feeling... as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea. that paradigm or at least the way we implement it might even mean more trouble than a synchronous counterpart. also, other editors that i feel will be sunset or not worked on at some point are atom and brackets.

I believe that his async code would have been far more maintainable / readable / expressive if it had used a reactive streams implementation such as colorless kotlin coroutines + flow. Sadly rust doesn't yet have one. What are your thoughts on this topic @raphlinus ?

I think this is not about coding style for async code (coroutines vs. callbacks), but about general asynchronity between various processes/threads.

If you have any asynchronous background task it means the state of your application can change without the current thread having made any change. And your code needs to account for that possibility, which makes it a lot more complicated.

Re: Xi-Editor Retrospective

#28

Post by chubot » Sat, Jun 27, 2020, 9:33 PM UTC

Tangent/clarification: the regex slowness issue is almost certainly due to using Perl-style exponential time regexes (which are required by Sublime syntax definitions) rather than "regular languages".

The syntect library mentioned uses fancy-regex, which is explicitly different than Rust's default regex crate, in that it supports regex constructs that require exponential backtracking:

https://github.com/fancy-regex/fancy-regex

In particular, it uses backtracking to implement "fancy" features such as look-around and backtracking, which are not supported in purely NFA-based implementations (exemplified by RE2, and implemented in Rust in the regex crate).

I think "regexes" have gotten bad name so I call them "regular languages" now. That is, RE2, rust/regex, and libc are "regular language" engines while Perl/Python/PCRE/Java/etc. are "regex" engines.

In my experience, lexing with regular languages can beat hand written code. In the case of Oil vs. zsh, it's beating hand-written C code by an order of magnitude (9-10x).

http://www.oilshell.org/blog/2020/01/parser-benchmarks.html

https://lobste.rs/s/77nu3d/oil_s_parser_is_160x_200x_faster_...

---

First, TextMate / Sublime style syntax highlighting is not really all that great. It is quite slow, largely because it grinds through a lot of regular expressions with captures

pedantic: I think the issue is probably more lookahead than captures ? You can do captures quickly in a "regular language" engine.

It may be surprising just how much slower regex-based highlighting is than fast parsers. The library that xi uses, syntect, is probably the fastest open source implementation in existence (the one in Sublime is faster but not open source). Even so, it is approximately 2500 times slower for parsing Markdown than pulldown-cmark.

Re: Xi-Editor Retrospective

#29

Post by m0zg » Sat, Jun 27, 2020, 9:43 PM UTC

This was solving problems nobody really has, so its fate was predictable. Here's what I think could take off like a rocket: a VSCode-like experience that runs completely in terminal, and therefore does not require a "remote" of any kind. Better yet if it takes most of the same plugins, to reuse the immense amount of work people have done there (and are not going to re-do for some hotshot new editor).

Note how none of the above mentions "async", "ropes" or "crdt".

Re: Xi-Editor Retrospective

#30

Post by an_opabinia » Sat, Jun 27, 2020, 9:45 PM UTC

chubot wrote: post #28

Tangent/clarification: the regex slowness issue is almost certainly due to using Perl-style exponential time regexes (which are required by Sublime syntax definitions) rather than "regular languages". The syntect library mentioned uses fancy-regex, which is explicitly different than Rust's default regex crate, in that it supports regex constructs that require exponential backtracking: https://github.com/fancy-regex/f…

The bigger problem I feel is with this:

> On the plus side, there is a large and well-curated open source collection of syntax definitions

Whenever I tried to get Java highlighting updated in GitHub for “var” my issue is closed minutes later by people who don’t work at GitHub telling me to open an issue with some random unpaid TextMate / Sublime repo.

Really the overall problem is not owning the front end. It means you can’t do things like fix syntax highlighting, at least as important to programming as high performance word wrap.