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

111–120 of 162 posts

Re: Xi-Editor Retrospective

#111

Post by jeffbee »

pokstad wrote: post #6

Is there another modern editor like Xi that strictly separates the GUI front end (view) from the backend (model and controller)?

Interesting juxtaposition of client/server with modernity. It seems really obsolete, in reality. Every kind of client/server UI system has been tried before. 20 years ago the idea that UI elements would run in the display server while sending commands to model/controller backends (over CORBA!) had a lot of traction. Of course, the idea sucks, so all of these projects are dead and buried. People think something valuable is buried there, so they keep digging the idea up again.

The real problem with the idea is that the user expectations of editor performance are high and the computer can only just barely do it. People expect to be able to open a 5GB file, have it drawn really nicely on a display with 30 million pixels, insert 1 character at the beginning of the file while the syntax highlighting updates instantly and then save and exit instantly. It's actually a lot of work for the machine, no room for RPC overhead.

Re: Xi-Editor Retrospective

#112

Post by MikusR »

taeric wrote: post #84
saagarjha wrote: post #48

Earlier quoted context omitted.

I think the point being made is that it is required for fast text rendering.

Still feels like that should not be the case. What changed so heavily in the last decade? 2d rendering used to be hella fast without the gpu. Right?

Those evil people like me that use letters outside ascii.

Re: Xi-Editor Retrospective

#114

Post by canofbars »

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.

What would be the point of building something that already exists?

Re: Xi-Editor Retrospective

#115

Post by RMPR »

fmakunbound wrote: post #86
vbezhenar wrote: post #64

Earlier quoted context omitted.

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.

That is a bizarre measure for a text editor.

It was a sarcasm

Re: Xi-Editor Retrospective

#116

Post by kzrdude »

saagarjha wrote: post #70
vbezhenar wrote: post #64

Earlier quoted context omitted.

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.

I am curious which editors pass this test, as pretty much everything I have tried chokes on long lines, even things like nano, vim, Sublime Text…

It's still disappointing, and I'd totally understand if someone wanted to fix this.

I think the pagers - less - is somewhat ok with long lines? Not much else that deals gracefully with multi megabyte lines.

Re: Xi-Editor Retrospective

#118

Post by jakear »

raphlinus wrote: post #66
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…

So, just syntax highlighting is not compelling to move out to a server. But part of my idea is that if you have async to hide server latency, so it's not slowing down typing, maybe you can do a much deeper analysis than just surface syntax. Right now you get basically instant coloring and then much slower but more accurate feedback that's generally comparable to an incremental recompile. I was thinking that a languag…

VS Code’s semantic tokens are a similar concept: an initial client side pass using a tmGrammar, then a language-server provided set of refinements.

https://code.visualstudio.com/api/language-extensions/semant...

Re: Xi-Editor Retrospective

#119

Post by saagarjha »

raphlinus wrote: post #81
mov_ wrote: post #80

On the github page https://github.com/xi-editor/xi-editor : JSON. The protocol for front-end / back-end communication, as well as between the back-end and plug-ins, is based on simple JSON messages. I considered binary formats, but the actual improvement in performance would be completely in the noise. Using JSON considerably lowers friction for developing plug-ins, as it’s available out of the box for most modern la…

Yes. In this discussion and on Reddit, people still talk about binary vs textual as the source of the problem, but I've argued (based on empirical data) that the lexical details are not the reason for the performance problems. Also, Swift is marketed as a fast language (also based on LLVM), yet in my measurements it's 20x to 50x slower than Rust for JSON processing. I found that surprising. Would you not?

Swift’s slowness is kind of unfortunate, although I hear that there is work being gone to remove a lot of the lifetime cruft that was going in behind the scenes to make it slow. And unfortunately I think the primary motivation for Swift’s performance is driven by its primary application, which is UI development, so “good enough” performance usually works…

Re: Xi-Editor Retrospective

#120

Post by ygra »

rudedogg wrote: post #67
microcolonel wrote: post #38

Earlier quoted context omitted.

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.

Not sure about other platforms, but I like the way macOS/iOS uses the accessibility metadata to look up UI elements for testing. So in order to "access" a button in a test, you have to do the accessibility work. You need it to take automated screenshots too.

It's the same on Windows. Automated UI testing almost always uses the accessibility APIs, both to find controls and to interact with them.
Post reply on HN