Live data from Hacker News

Xi-Editor Retrospective

raphlinus.github.io

121–130 of 162 posts

Re: Xi-Editor Retrospective

#121
post #32

The assertion that gpu is required for good text rendering caught me off guard. I can't claim it is wrong, but it does feel like it should be wrong.

Sublime Text 3 still exclusively uses CPU rendering. Unless you're working with really high resolutions (think 8k), CPU rendering is plenty fast.

Doesn’t Sublime Text have an option somewhere to use a GPU buffer or something once your resolution passes some reasonable limit (I think 2560)? What does that do?

Re: Xi-Editor Retrospective

#122
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 valuab…

Is this not exactly how macOS does input dispatch? Input comes in from the HID subsystem in the kernel and is redirected by WindowServer to the right application via Mach which queues it on its runloop, and then it updates its view and tells WindowServer again via Mach to composite that to the screen?

Re: Xi-Editor Retrospective

#123

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 b…

I found some interesting ones in this thread!

Re: Xi-Editor Retrospective

#125
> When doing some performance work on xi, I found to my great disappointment that performance of these so-called “native” UI toolkits was often pretty poor, even for what you’d think of as the relatively simple task of displaying a screenful of text.

The same thing I experienced. Text rendering performance is terrible with Cocoa, and even worse with Win32. Calculating text width is an order of magnitude slower than with FreeType.

That's why for my UI framework I also went from using "native" APIs to custom GPU rendering.

Re: Xi-Editor Retrospective

#127
post #58

Earlier quoted context omitted.

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 togethe…

Two reasons: captures, and it needs to know which of the regexes matched. I meant to but forgot to mention in my original comment that the reason Sublime's built-in highlighter is the fastest is they wrote a custom regex engine which basically does the equivalent of or-ing them together but unlike all other regex engines handles captures and information about which one matched properly while doing so. The custom engi…

re2c supports captures and it will tell you which regex matched. http://re2c.org/manual/manual.html#submatch-extraction

Re: Xi-Editor Retrospective

#128

Earlier quoted context omitted.

Sublime Text 3 still exclusively uses CPU rendering. Unless you're working with really high resolutions (think 8k), CPU rendering is plenty fast.

Doesn’t Sublime Text have an option somewhere to use a GPU buffer or something once your resolution passes some reasonable limit (I think 2560)? What does that do?

From the settings:

  // Mac only. Valid values are true, false, and "auto". Auto will enable
  // the setting when running on a screen 2560 pixels or wider (i.e., a
  // Retina display). When this setting is enabled, OpenGL is used to
  // accelerate drawing. Sublime Text must be restarted for changes to take
  // effect.
  "gpu_window_buffer": "auto",

Re: Xi-Editor Retrospective

#129

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…

One important thing to note is that all your examples of custom text are non-rich editors. Text editing becomes astonishingly more difficult if proper rich text and i18n is required. Then, Core Text / TextKit is a pretty good solution because anything else quickly requires years of work. The best alternative I know of is using a Javascript-based editor in a WebView - or jumping to something like Qt.

Re: Xi-Editor Retrospective

#130
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 don't want to speak too much for raphlinus here [1], but I don't think it was ever the goal to make an editor that gets a lot of downloads like a startup pitching a product. All the things you've listed are non-goals, or at least lower-priority goals. The goal was to make an editor based on sound technology principles, and that included investigating said technology principles. It turned out some of those principle…

That's a long way of saying it's a 'research project' or an 'experimental text editor' written in Rust.
Post reply on HN