Live data from Hacker News

Xi: an editor for the next 20 years [video]

recurse.com

101–110 of 306 posts

Re: Xi: an editor for the next 20 years [video]

#101
post #98

"Platform text rendering (CoreText, DirectWrite) not performant enough" That above needs some reliable proof to be honest. I am testing this claim with Sciter ( https://sciter.com )... On Windows Sciter uses Direct2D/DirectWrite (with an option to render on DirectX device directly) and/or Skia/OpenGL. On Mac it uses Skia/OpenGL with an option to use CoreGraphics. On Linux Cairo or Skia/OpenGL. Here is full screen tex…

> On window caption you see real FPS that is around 500 frames per second for the whole screen for the sample.

Sure, 500 fps, but that's not the important part. Latency would be. So at 500 fps with how much output latency to the display?

Re: Xi: an editor for the next 20 years [video]

#102
post #64

Earlier quoted context omitted.

What's your reasoning behind needing it to be a default install? seems an odd requirement for an editor. For instance, notepad is default on windows, and I'll use that when needed on vanilla windows machines, but for the 99% of my editor needs I install and customize a number of enviroments (including Vim). I don't mind whether it's installed by default or not.

I am guessing he works at a place that has a lot of servers that he connects to, and he wants to be able to use his editor on whatever server he is on. I know this is an issue where I work. We have 40 thousand plus servers, and we aren't going to have everyone install their editor of choice on all those machines. If I have an issue I need to check on a server that requires some text editing, I have to use one of the…

This is the appeal of sshfs - to be able to easily mount remote filesystems and use local tools against them.

Re: Xi: an editor for the next 20 years [video]

#103

Earlier quoted context omitted.

For the protocol between core and front-end, did you take any inspiration from mosh's state sync protocol? https://mosh.org/mosh-paper-draft.pdf

Text editors shouldn't have a "core" and "front end" and "protocol". Monolithic machine executable that fits into under a meg of RAM and comes up in a fraction of a second from a cold invocation.

Separating these concerns doesn’t strictly preclude (or at least needn’t strictly preclude) shipping a single, sub-megabyte binary.

The “classic example” of this would be Quake — a single binary implements both a server and a client, which communicate over a simple binary protocol.

Re: Xi: an editor for the next 20 years [video]

#104
post #53

Earlier quoted context omitted.

Just found https://github.com/acheronfail/xi-electron but actually I was more thinking of running the whole editor in the browser, not just the frontend.

Do any of the latency advantages of Xi carry over if you wrap it all up in Electron? The Electron editors do pretty badly on this front [1]. [1] https://pavelfatin.com/typing-with-pleasure/

I haven't started measuring it yet, but plan to. The idea of keeping the UI component light and doing all the heavy lifting in the core _might_ work well in Electron (as opposed to having all the logic in JS), and xi-electron is a good testbed for exploring that.

Re: Xi: an editor for the next 20 years [video]

#105
post #52

Pragmatically speaking the issue with switching editors is the fact that if it is not emacs or vi it is not a default install on whatever you sit down at. I have tried tons of editors, and I always come back to vim. Heck, I have even moved my .vimrc to be the simplest possible with the smallest number of plugins.

Even emacs is not installed by default on most operating systems. Even worse a lot of people customize their emacs setup so much that using the default setting can be painful.

I use tramp-mode to connect to remote systems, which provides comfortable editing without requiring anything other than ssh access to the target machine. It’s quite nice.

Re: Xi: an editor for the next 20 years [video]

#106
post #98

"Platform text rendering (CoreText, DirectWrite) not performant enough" That above needs some reliable proof to be honest. I am testing this claim with Sciter ( https://sciter.com )... On Windows Sciter uses Direct2D/DirectWrite (with an option to render on DirectX device directly) and/or Skia/OpenGL. On Mac it uses Skia/OpenGL with an option to use CoreGraphics. On Linux Cairo or Skia/OpenGL. Here is full screen tex…

This is awesome. Thank you for sharing.

Re: Xi: an editor for the next 20 years [video]

#107

Earlier quoted context omitted.

Can you please comment on Xi as a general editor and specifically in relation to vim and Emacs, arguably the two best general editors from the last few decades. Thanks!

I don't want to knock either, they're both obviously great editors. My main goal is to build something that feels entirely like a native app. Also, I'm hoping that the async model for plug-ins will preserve responsiveness even when there are a lot of plug-ins and they do nontrivial work.

> My main goal is to build something that feels entirely like a native app.

It's not clear to me how this relates to the question. Emacs and vim are native apps.

Re: Xi: an editor for the next 20 years [video]

#108

What's the best Windows build for this?

I believe it will eventually live at https://github.com/google/xi-win , though I think the focus is on getting the Mac version working first.

Indeed. I was hoping to put more effort into xi-win than it's gotten, but for a variety of reasons have decided to focus on the macOS front end for now, as there's quite a bit of work remaining to get a daily-usable editor up on one platform.

Re: Xi: an editor for the next 20 years [video]

#109
post #82

> modern text editor with uncompromising performance Solution in search of a problem. I haven't run into an editor performance issue in more than twenty years. I will gladly trade a hundred text editor performance fixes for one web browser performance fix .

That's because you (probably) haven't used a modern text editor. If you'd follow either chrome's or firefox's changelog you'd also read about constant progress in optimizing their browser engine and dev tools.

> That's because you (probably) haven't used a modern text editor.

Can you provide an example? Because I've worked on > 1MM line projects in IntelliJ with no performance issues, or at least none related to text editing.

Re: Xi: an editor for the next 20 years [video]

#110
post #81

Earlier quoted context omitted.

"Easy" is not the right word for this, but it's possible. One challenge is that browsers don't export an interface for "shaping". For Latin script, that means kerning and ligatures, and for complex scripts, it means being able to render it correctly at all. Currently, alacritty doesn't really deal with this, but xi-mac does, using the interfaces provided by Core Text.

Figma (a UI design tool written in C++ compiled to JS using emscripten) talked about this briefly in their tech blog. They compiled FreeType to JS for rendering fonts to bitmaps: https://blog.figma.com/building-a-professional-design-tool-o...

Figma actually only uses FreeType for parsing fonts (fonts are rendered using a custom WebGL-based renderer). Figma uses HarfBuzz for text shaping, which is easy to run on the web with emscripten: https://github.com/harfbuzz/harfbuzz.
Post reply on HN