61–70 of 162 posts
Earlier quoted context omitted.
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
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…
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…
This postmortem says Rust was, and still is, a great fit for the problem domain for which it was used.
Where do you reach the conclusion that Rust is bad for UI-intensive apps? That claim appears to have no relation to the post-mortem as Xi didn't use Rust for the UI in the first place? Things might have been better if Rust was used for the UI if anything, as attempting to be native instead was one of the problem areas.
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?
> 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.
> 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…
Perhaps an even better motivation is indentation. When I use editors with regex-based indentation (the norm), I'm regularly annoyed when it gets it wrong. Being able to budget a few milliseconds or tends of milliseconds to do indentation that exactly matches what rustfmt or gofmt would recommend would be worth it, imho.
> 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.
You need it to take automated screenshots too.
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…
First, syntect can use both onig (an adaptation of Ruby regex, same as Sublime) and fancy-regex. The latter is yet another xi-instigated, and was motivated by trying to do a better job at this. Second, the design of fancy-regex is precisely to delegate to the regex crate when features like lookahead aren't needed. I had high hopes for the performance, but it turned out to be lackluster, a highly tuned backtracking en…
https://lobste.rs/s/fq8uil/aho_corasick
https://news.ycombinator.com/item?id=23665341
I don't have experience with captures in re2c, but it's entirely automata-based, and they apparently implement something "fast" for captures and published it in this 2017 paper, so it's pretty new:
https://arxiv.org/abs/1907.08837
I'm sort of interested in benchmarking some Sublime-ish workloads with it, but I'm not sure I'll have time.
----
And the other claim from that comment is that while regular languages aren't powerful enough by themselves for syntax highlighting, you can add a trivial state machine on top of them (perhaps Vim-like), and get something more powerful and faster than Sublime's model.
I'd have to look at the captures vs. lookahead issue more closely, but the general claim is that I think Sublime has a bad parsing model based on a sloppy application of Perl-style regexes (e.g. if you are really forced to read every byte multiple times, that seems dumb, and can be avoided with regular languages)
Earlier quoted context omitted.
Your server generally has a better idea about the language than you do, presumably.
I would only think that's the case when the language of the file you're editing is unknown, so you would have to do some server-side analysis of the entire file and make an educated guess. For example, https://github.com/github/linguist . But if the language is known in advance, then you could send the grammar rules to the client.
Earlier quoted context omitted.
No, where does it go? Are the big editors unsuccessful?
My first test of any text editor is to open something like 4-gigabytes log file with one gigabyte line. If editor works fast, it's good. So far very few editors pass this test, so most are not suitable for general use, only for some niche use like editing tiny text files.