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

131–140 of 162 posts

Re: Xi-Editor Retrospective

#131

Post by mwcampbell »

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.

Implementing enough accessibility to enable automated testing is a good start, but unless you're aware of the needs of people using screen readers and other assistive technologies (and possibly incorporate those requirements into your automated tests), you won't automatically get full accessibility just by exposing the information that your tests need in order to control the UI.

Re: Xi-Editor Retrospective

#132

Post by mwcampbell »

amedvednikov wrote: post #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 w…

If your framework has a broad audience, please make sure it accounts for the full complexity of text rendering [1] and editing [2], particularly when it comes to internationalization. You may find that there are good reasons for Cocoa to be as slow as it is in the measurement phase, if not the rendering phase. And of course, please don't forget about accessibility.

[1]: https://gankra.github.io/blah/text-hates-you/

[2]: https://lord.io/blog/2019/text-editing-hates-you-too/

Re: Xi-Editor Retrospective

#133

Post by vbezhenar »

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…

I finally stopped on Windows EditPad, but it's shareware and its UI is somewhat weird, so I won't recommend it for everyone, but as a general text editor, it works for me.

Re: Xi-Editor Retrospective

#134

Post by jjgod »

gnachman wrote: post #75
taeric wrote: 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.

I sure wish it were wrong. If macOS’s text rendering primitives could be used asynchronously or concurrently the situation would be significantly better. I’ve spent probably hundreds of hours trying to make it fast but I’m convinced it’s only possible if you work at Apple (as they have done quite well with Terminal by using lots of hacks that are unavailable to me)

What do you mean by “primitives” here?

Re: Xi-Editor Retrospective

#135

Post by fluffything »

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…

> Surprising reasons?!

It is possible to write a blazing fast JSON serializer/deserializer on pretty much every programming language, and most languages have many of them.

Swift does not, and it does not seem that it will have one in the near future. This is quite disappointing, taking into account that Swift is one of the 3 major-platform native languages (C# windows, swift macos, C on Linux).

So yeah, it is quite surprising that the major platform language in one of the main platforms in use has extremely poor JSON support. Even more surprising is that there is no path forward to fix that.

There are many pros/cons of using json, but this was a "non issue" (if it isn't fast enough, we can make it fast - turns out we cannot because the platform is controlled by Apple and they don't want to).

Re: Xi-Editor Retrospective

#136

Post by fluffything »

cjohansson wrote: post #25

Front-end / interace needs to be synchronously controlled, it doesn’t feel right otherwise. I followed xi-editor but it never was faster than emacs on opening really large files and editing them so it never had a use case for me

I use emacs full time, and I open large files on xi (>300 GB). When I handle files in the 500 MB-10 GB range on emacs, I basically need to disable everything and use "text-mode" exclusively, and yet it still struggles if the file is only a couple of GBs long....

Re: Xi-Editor Retrospective

#137

Post by fluffything »

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?

> 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 resize the screen and scroll, resize text, with great fonts, without any delay or sluggishness.

Xi delivered in some of those things, and druid delivers on some of the others.

But essentially, 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 - not the fastest but much faster than most text editors.

The idea behind Xi was to preserve that as the editor got more features, like syntax highlightning, and it did.

Re: Xi-Editor Retrospective

#138

Post by fluffything »

Maybe the time is just not right for Xi yet.

I wish that after druid becomes production ready you'll pick it up again.

The coolest thing about Xi is that some have attempted to make it a vim replacement, others an emacs replacement, etc. I wish it becomes a framework that can be used to build better text editors in general.

Re: Xi-Editor Retrospective

#139

Post by ilrwbwrkhv »

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.

Atom is open source. The community can always keep working on the project if they care.

Re: Xi-Editor Retrospective

#140

Post by raphlinus »

fluffything wrote: post #138

Maybe the time is just not right for Xi yet. I wish that after druid becomes production ready you'll pick it up again. The coolest thing about Xi is that some have attempted to make it a vim replacement, others an emacs replacement, etc. I wish it becomes a framework that can be used to build better text editors in general.

I also hope to be able to pick up text editing again, but make no promises. If not, then I hope Druid provides a solid foundation for others to build the dream editor I envisioned.
Post reply on HN