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

41–50 of 162 posts

Re: Xi-Editor Retrospective

#41

Post by raphlinus »

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.

Re: Xi-Editor Retrospective

#42

Post by stephc_int13 »

akhilcacharya wrote: post #39
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.

Perhaps this is a cultural side effect?

You mean working at Google or in the Android team?

I've rarely seen a worse example of absurdly over-engineered code than the Android codebase...

Re: Xi-Editor Retrospective

#43

Post by eeereerews »

microcolonel wrote: post #37
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.

The thing is, that is the story of the existing big editors, and we know where that story goes.

No, where does it go? Are the big editors unsuccessful?

Re: Xi-Editor Retrospective

#44

Post by akhilcacharya »

stephc_int13 wrote: post #42
akhilcacharya wrote: post #39

Earlier quoted context omitted.

Perhaps this is a cultural side effect?

You mean working at Google or in the Android team? I've rarely seen a worse example of absurdly over-engineered code than the Android codebase...

The latter includes the former, so yes.

Re: Xi-Editor Retrospective

#45

Post by microcolonel »

eeereerews wrote: post #43
microcolonel wrote: post #37

Earlier quoted context omitted.

The thing is, that is the story of the existing big editors, and we know where that story goes.

No, where does it go? Are the big editors unsuccessful?

They are unscalable.

I love Emacs, and it continues to be my editor of choice, but it doesn't seem the design is amenable to adding good threading primitives. NeoVIM seems like a success story in this regard, though VIMScript is a much less pleasant extension language than Elisp, which is not perfect, but is at least a real programming language.

There may be a way forward for Emacs, building a sandbox that looks like a full Emacs instance to existing Elisp, and slowly factoring out the whole-editor blocking issues; but that might be almost as complicated as starting fresh, with fewer benefits.

Re: Xi-Editor Retrospective

#46

Post by saagarjha »

microcolonel wrote: post #38
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…

The accessibility APIs can be programmed against by anyone. If there is a way to make something like this accessible to screen readers in some useful way, it would likely involve specific accessibility work either way.

Platform widgets do a lot of the accessibility work for you. In some cases you can get away with doing zero* work.

*Or very close to zero

Re: Xi-Editor Retrospective

#47

Post by magicalist »

eeereerews wrote: post #43
microcolonel wrote: post #37

Earlier quoted context omitted.

The thing is, that is the story of the existing big editors, and we know where that story goes.

No, where does it go? Are the big editors unsuccessful?

> Are the big editors unsuccessful?

No, but if that's the only criteria, we already have plenty of those.

Re: Xi-Editor Retrospective

#49

Post by mwcampbell »

microcolonel wrote: post #38
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…

The accessibility APIs can be programmed against by anyone. If there is a way to make something like this accessible to screen readers in some useful way, it would likely involve specific accessibility work either way.

> If there is a way to make something like this accessible to screen readers in some useful way

If by "something like this" you mean a text editor, then there's no question; they can be made accessible with a screen reader, and some complex ones (e.g. Visual Studio Code, Visual Studio, and Xcode) are accessible already.

> it would likely involve specific accessibility work either way.

For the main UI of a full-featured programmer's editor or word processor, that's definitely true.

What I want to avoid is developers using a custom GUI toolkit where the platform's native toolkit would do, because they want the best possible performance (regardless of whether the platform's toolkit is good enough), and forfeiting all of the accessibility benefits that the platform's native toolkit brings more or less automatically.

Re: Xi-Editor Retrospective

#50

Post by saagarjha »

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…

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?
Post reply on HN