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

141–150 of 162 posts

Re: Xi-Editor Retrospective

#141

Post by smichel17 »

rl3 wrote: post #98

> One of those was learning about the xray project. I probably shouldn’t have taken this personally, ... I've run into that phenomenon a lot with various startup projects over the years. It's soul crushing, and often an immediate reaction is to assume certain projects are direct competition, rendering your project fruitless. In retrospect, this ends up almost never being the case. In a way, you become your own worst…

It's not a startup and the alternatives are not competitors, but I've had a similar experience affecting my motivation to work on Red Moon.

There's two other screen filter apps on F-Droid, and at one point I proposed that we [work together], either merging our apps or creating shared libraries. While the other devs initially expressed some interest, they weren't willing/able to put in the effort and nothing came of it. This has killed my motivation to work on Red Moon. It feels like a waste of time, duplicating other people's efforts.

That's not intrinsic to other people working separately to solve the same problem. If Red Moon were an educational project, or if it took a unique approach to screen filtering (like the other project I'm part of and [crowdfunding]), then I'd feel differently. But my main motivation was creating a FLO screen filter app, since previously I depended on the proprietary Twilight. And while there's a handful of valid approaches to screen filtering, the bulk of the effort is on UX, state transitions, and working around the kinks of Android, all of which are shared.

Note: I don't bear any hard feelings towards the other devs, genuinely -- the most frustrating bit was [lack of communication], and even that is totally understandable; it's hard to say no to something you like the idea of, even to yourself (eg, acknowledging you'll never get to that project near the bottom of your list).

[work together]: https://github.com/LibreShift/red-moon/issues/222

[lack of communication]: https://github.com/LibreShift/TransitionScheduler/issues/14

[crowdfunding]: https://wiki.snowdrift.coop/market-research/other-crowdfundi...

Re: Xi-Editor Retrospective

#142

Post by taeric »

fluffything wrote: post #137
taeric wrote: post #84

Earlier quoted context omitted.

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?

> 2d rendering used to be hella fast without the gpu. Right? Define Hella fast. If you want 16ms text rendering (~60 Hz) you pretty much need a GPU today. If you want 8ms (120Hz) text rendering, there is just no CPU that can handle it today with an OS running next to your text editor doing other stuff. The whole point of Xi was being able to edit huge files (Tb size) on 8k displays at over 120 Hz, and being able to r…

Do you have good benchmarks going over this? Still feels ridiculous. I have a multi core machine running at speeds well above my comprehension and you are saying they can't render simple 2d primitives at speed? That just blows my mind. What are they spending the time on?

I get that rendering a full display from scratch could be slow. But updating a single key press should not be. Scrolling? Sure. I guess. But even that feels like we over complicated something in the process.

I note that I do not disbelieve you. My asserting that it is ridiculous is that it sounds ridiculous.

Re: Xi-Editor Retrospective

#143

Post by Myrmornis »

fluffything wrote: post #137
taeric wrote: post #84

Earlier quoted context omitted.

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?

> 2d rendering used to be hella fast without the gpu. Right? Define Hella fast. If you want 16ms text rendering (~60 Hz) you pretty much need a GPU today. If you want 8ms (120Hz) text rendering, there is just no CPU that can handle it today with an OS running next to your text editor doing other stuff. The whole point of Xi was being able to edit huge files (Tb size) on 8k displays at over 120 Hz, and being able to r…

> there is no system today where you press a key and that key appears on your screen in less than 8ms. Xi achieves ~16ms on the right platforms

How does one measure this? Say for the text editor I'm using (Emacs) or for Chrome/Google Docs?

Re: Xi-Editor Retrospective

#144

Post by Myrmornis »

I (naively) would have thought that the IPC / multi-process model strongly conflicted with the extremely high performance goals (e.g. time between keypress and painting). Can anyone explain why my instinct there is wrong?

Re: Xi-Editor Retrospective

#145

Post by taeric »

raphlinus wrote: post #105
taeric wrote: post #95

Earlier quoted context omitted.

Do you have any good reads on the difference in format that you are referencing? (Linear versus whatever the gpu is doing?) Even sending the buffer to the gpu for compositing makes sense as a problem, but still feels that should be faster than you would care about in a text editor. I'm also on a mac that, if I do something that is "gpu accelerated", I'm likely to get a frozen session. Such that most applications don'…

Very likely, the specific thing you're experiencing is poorly-engineered switching between integrated and discrete GPUs. It's not a mac-only problem, see this thread for a somewhat horrifying story (follow last link): https://www.reddit.com/r/gigabyte/comments/91ld3o/aero_15x_d... A good intro to layout transitions is: https://www.gamasutra.com/blogs/EgorYusov/20181211/332596/Ta... The number of copies required to ge…

This all makes sense. But I would have imagined my machine can perform several hundred copies in the time it used to take to do one. Haven't memory speeds progressed a fair bit?

Such that I agree it would be better to do dirty tracking and sending just a small update to the screen. But the tricks to do that should be a lot easier than they used to be.

The gpu thing in my Mac is amusing just because if I run intellij, it will cause my machine to crash. If I run emacs? Not so much. Even if I am stressing the machine with several compiles or some silly pandas data frames. If I enable gpu accelerations in my browser? Expect instability. My video chat program just boasted that they use gpu for video. And for the past two weeks, it is common for the entire video system of my machine to hang during a video chat... Literally get a crash screen.

Re: Xi-Editor Retrospective

#146

Post by ComputerGuru »

sq_ wrote: post #3
blondin wrote: post #2

had that feeling... as a side note, i think more and more people are starting to realize that the async paradigm is not a panacea. that paradigm or at least the way we implement it might even mean more trouble than a synchronous counterpart. also, other editors that i feel will be sunset or not worked on at some point are atom and brackets.

Atom already seems to have gone somewhat towards maintenance mode since Microsoft bought Github. Feels like there's a lot less by way of features being released and a lot more just keeping up with ecosystem/OS changes. I could certainly be wrong though.

I don’t see anything wrong with that, tbh. While it’s apples and oranges to compare atom to sublime, I think in an extremely fair and objective head-to-head comparison between VS Code and Atom, the latter is just a worse choice on all fronts. It came first, it filled a need, and now there’s something better.

(And it and that something better is now both owned/maintained by the same organization, making it even more of a no-brainer to slowly phase the inferior option out.)

Re: Xi-Editor Retrospective

#147

Post by jhoechtl »

saagarjha wrote: post #9

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…

Concerning LSP I can assure you that my NeoVim with native lsp support is great. Maybe because the situation before was just downright very bad so what we have now is just so much better.

Re: Xi-Editor Retrospective

#148

Post by microcolonel »

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…

Emacs has made some major improvements with long lines in master, and some of that will come out with 27.

Re: Xi-Editor Retrospective

#149

Post by BooneJS »

__s wrote: post #91
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…

What you're asking for exists: https://github.com/neoclide/coc.nvim

"Step 1: Install NodeJS"

I think what got people excited about Xi with Ropes and CRDT and Rust was that it was going to be a modern codebase with performance. Now that Moore's Law is buried next to Denard scaling, we need less software written with time-to-MVP in mind and more software written with performance in mind. Software is used a lot more than it's created. If I looked at editors like emacs and vi/vim/neovim, and tried to calculate the person-decades spent making them vs. the person-millennia spent using it, it's quite clear that optimizing for the single-core performance we have today pays off tomorrow when singe-core performance is 10% faster.

Re: Xi-Editor Retrospective

#150

Post by [deleted] »

BooneJS wrote: post #149
__s wrote: post #91

Earlier quoted context omitted.

What you're asking for exists: https://github.com/neoclide/coc.nvim

"Step 1: Install NodeJS" I think what got people excited about Xi with Ropes and CRDT and Rust was that it was going to be a modern codebase with performance. Now that Moore's Law is buried next to Denard scaling, we need less software written with time-to-MVP in mind and more software written with performance in mind. Software is used a lot more than it's created. If I looked at editors like emacs and vi/vim/neovim,…

[deleted]
Post reply on HN