Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xi-Editor Retrospective

raphlinus.github.io

Post reply on HN
Print view View original

51–60 of 162 posts

Re: Xi-Editor Retrospective

#51

Post by noobermin »

stephc_int13 wrote: post #36

Too much over-engineering here. It is always better to start with simple, dumb and reliable code, with minimal architecture, and then grow organically. With experience, I tend to write the less smart code possible, I felt in love with the power of brute-forcing everything.

From the little of what I knew about Xi, I came in with this perspective. The article changed my mind. He really was trying to "fix all the problems" as it were, it's right there in the start of the article the issue with google keyboard not talking to text boxes, it's a problem that is real. That said, in his opinion, it didn't work especially with the gui being separate from the core.

I guess my point is he was trying to "correctly solve" a hard problem, which does require engineering. He didn't seem to set out to solve a dumb problem that didn't need solving (Yet Another Text Editor).

Re: Xi-Editor Retrospective

#52

Post by bhl »

> And it [syntax highlighting] basically doesn’t fit nicely in the CRDT model at all, as that requires the ability to resolve arbitrarily divergent edits between the different processes (imagine that one goes offline for a bit, types a bit, then the language server comes back online and applies indentation).

What's a rationale for having syntax highlighting server-side as opposed to client-side? I'm working on side project that uses ProseMirror and CRDTs through yjs, and the idea of having a server for syntax highlighting for editable text never occurred to me.

> Even so, xray was a bit of a wake-up call for me. It was evidence that the vision I had set out for xi was not quite compelling enough that people would want to join forces.

I think in hindsight this was a virtue. If you look at the xray project, it died after the Microsoft acquisition of Github: https://github.com/atom-archive/xray/issues/177. By not combining projects, it allowed for redundancy.

Re: Xi-Editor Retrospective

#53

Post by mwcampbell »

raphlinus wrote: post #41
mwcampbell wrote: post #34

> There is no such thing as native GUI I understand why you were disillusioned with the performance of native GUIs. But in other areas, such as accessibility, nativeness absolutely does help. I'm guessing you know this; I just want to make sure other developers get this message. Here is a quite comprehensive list of the benefits of a native GUI for accessibility, particularly on macOS: https://news.ycombinator.com/it…

Very good point, and accessibility is important. We do have it on our longer-term roadmap for Druid, and until it's done it's a very good reason to consider it unfinished work-in-progress. I will make sure to discuss this in my follow-up blog, which is about building GUI. Thanks.

I'm looking forward to that follow-up post, especially the part about toolkits that make heavy use of the compositor to work around rendering limitations. I also wonder if the Chromium rendering engine is doing the same thing, and if not, how its performance compares to, say, WinUI and Cocoa.

Re: Xi-Editor Retrospective

#54

Post by bhl »

sq_ wrote: post #14
andrewflnr wrote: post #5

Earlier quoted context omitted.

Atom competes pretty directly against VS Code doesn't it? It makes sense that Microsoft would consolidate their efforts.

That's what I thought, too. Hopefully the team that was working on Atom has gotten/will get a chance to bring some of its components/features to VS Code if it doesn't already have them.

There was this one comment when Github Codespaces got released that that's where ex-Atom devs got moved to: https://news.ycombinator.com/item?id=23093150

Re: Xi-Editor Retrospective

#55

Post by saagarjha »

m0zg wrote: post #29

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…

I think it had a lot of goals that matched I'd like from my text editor:

* Using native technologies

* Fast

* Modular and extensible

* Open source

Re: Xi-Editor Retrospective

#56

Post by saagarjha »

bhl wrote: post #52

> And it [syntax highlighting] basically doesn’t fit nicely in the CRDT model at all, as that requires the ability to resolve arbitrarily divergent edits between the different processes (imagine that one goes offline for a bit, types a bit, then the language server comes back online and applies indentation). What's a rationale for having syntax highlighting server-side as opposed to client-side? I'm working on side p…

Your server generally has a better idea about the language than you do, presumably.

Re: Xi-Editor Retrospective

#57

Post by magicalist »

stephc_int13 wrote: post #36

Too much over-engineering here. It is always better to start with simple, dumb and reliable code, with minimal architecture, and then grow organically. With experience, I tend to write the less smart code possible, I felt in love with the power of brute-forcing everything.

> With experience, I tend to write the less smart code possible

I'm always amused by the hn threads patting ourselves on the backs for in depth technical discussions[1], when so often the top comments are basically non-specific thought leader tweets.

For those that got this far, the article is well worth reading about a design space with difficult tradeoffs, and there are comments actually engaging with the content below this.

[1] today brings us multiple instances in https://news.ycombinator.com/item?id=23664067

Re: Xi-Editor Retrospective

#58

Post by chubot »

trishume wrote: post #35
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…

Author of syntect here: This isn't why TextMate/Sublime/VSCode/Atom style regex parsing is slow. The main reason is that the parsing model is applying a whole bunch of unanchored regexes to the unparsed remainder of the line one after another until one matches, then starting again for the next token. This means each token parsed can require dozens of regex matches over the same characters. I implemented a bunch of ca…

The main reason is that the parsing model is applying a whole bunch of unanchored regexes to the unparsed remainder of the line one after another until one matches, then starting again for the next token. This means each token parsed can require dozens of regex matches over the same characters.

Hm but why can't you just OR them together? That is perfectly fine with a regular language engine. For example, I OR together about 50 different regexes here (including a whole bunch of constant strings) for the ShCommand mode:

https://www.oilshell.org/release/0.8.pre6/source-code.wwz/_d...

Despite this big mess, everything "just works", i.e. the lexer reads every byte of input just once. re2c picks the alternative with longest match, and it picks the first match to break ties.

-----

I suspect the reason that you can't do this is (1) Sublime was originally implemented with a Perl-style regex engine and (2) the order of | clauses matters more when using a backtracking engine. It doesn't have the simple rule that an automata-based engine has.

My claim is that you avoid performance problems by using a "regular language" engine. So I think what you point out supports this, even it might be a slightly different issue than "more backtracking".

I think you are saying that Sublime's parsing model prevents composition by |, which makes lexing slow, because it forces you to read each byte many times. (in addition to the captures issue, let me think about that)

Re: Xi-Editor Retrospective

#59

Post by m0zg »

saagarjha wrote: post #55
m0zg wrote: post #29

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…

I think it had a lot of goals that matched I'd like from my text editor: * Using native technologies * Fast * Modular and extensible * Open source

And I'm not disputing that. But one goal eclipses all others:

* Usable

Re: Xi-Editor Retrospective

#60

Post by raphlinus »

saagarjha wrote: post #50
trishume wrote: post #35

Earlier quoted context omitted.

Author of syntect here: This isn't why TextMate/Sublime/VSCode/Atom style regex parsing is slow. The main reason is that the parsing model is applying a whole bunch of unanchored regexes to the unparsed remainder of the line one after another until one matches, then starting again for the next token. This means each token parsed can require dozens of regex matches over the same characters. I implemented a bunch of ca…

This is probably already implemented if it does exist, but I know with a bunch of fixed text strings you can create a NFA/trie thing using Aho-Corasick. Does such a thing exist for regexes (specifically: one that can match "all of them at once"), and is it used for the fast regex engine?

You will probably find https://github.com/BurntSushi/aho-corasick/blob/master/DESIG... good reading. I believe captures get in the way of using the fastest of these NFA-style techniques, though. There's a comment from burntsushi to this effect in: https://lobste.rs/s/fq8uil/aho_corasick

ETA: Heh, I'm amused to find the latter link to be another point in what seems to be an extended conversation between Andy Chu and the Rust text-processing community :)

Post reply on HN