Live data from Hacker News

Xray – An experimental next-generation Electron-based text editor

github.com

211–220 of 240 posts

Re: Xray – An experimental next-generation Electron-based text editor

#211
post #141

Earlier quoted context omitted.

> it's expensive one too It's $80. If you work in text all day, then that's practically nothing. It's kind of disheartening to see how little value people place on excellent software.

All the compilers I bought during the 90's, using student discounts, would allow me to buy several copies of Sublime Text in today's money. It is that mentality that killed the market of nice tools for developers. Now everyone that wants to live from software tools has to target the enterprise market, where the tool won't cost $80 but a few hundred if not thousands.

That mentality is created by capitalism. Corporations need to push people into software engineering and attract software engineers, which in turn creates an incentive for free and open tooling for developers.

Re: Xray – An experimental next-generation Electron-based text editor

#212

Earlier quoted context omitted.

> it's expensive one too It's $80. If you work in text all day, then that's practically nothing. It's kind of disheartening to see how little value people place on excellent software.

That's easy for you to say, as a (presumably) rich American developer. It's a different story in, say, India or Africa, or students or poor folks. $80 can be several days or weeks of sustenance.

True. Most of the world cannot afford to pay $80 for a text editor.

Re: Xray – An experimental next-generation Electron-based text editor

#213

Earlier quoted context omitted.

> They sacrifice memory usage for development pace. This is a false dichotomy. Vanilla Emacs needs 38Mb on my machine, and it has all the tools you'd ever need to develop plugins for it. Visual debugger, byte-compiler, object inspector, jump to definition (including straight to C implementation when needed), visual font pickers, color palette, documentation browser & docstring viewer for symbol at point, you name it…

The DOM is about the worst structure for text editing I can think of..

Yeah, reminds me of this post: https://ecc-comp.blogspot.com/2015/05/a-brief-glance-at-how-...

There's a simple array of lines, a gap buffer, a BTree... No DOM, though. I wonder why... :)

Re: Xray – An experimental next-generation Electron-based text editor

#214
post #203

Earlier quoted context omitted.

>Luajit is the only dynamic language runtime that's faster than V8, Also Common Lisp ( much faster than V8), Forth, and probably some Scheme implementations.

To pick nits: Forth is not "dynamic"; words are called by their direct addresses, without any hashtable lookup. It's a stark contrast with Python, Ruby, JS, etc.

To be fair, with CREATE/DOES> you can make them do any lookup you want easily. Well, as easy as anything in Forth.

Re: Xray – An experimental next-generation Electron-based text editor

#215
post #162

Earlier quoted context omitted.

The linter was the issue. I actually have better performance with Sublime Text and JavaScript than I do with vim and JavaScript. I wish that weren’t the case. If you know if any better ways to get vim working with Syntastic for linting (eslint), I would love to know.

Switch syntastic for ale: https://github.com/w0rp/ale It's asynchronous if you're running vim8+

Awesome, thanks for this!

Re: Xray – An experimental next-generation Electron-based text editor

#216

Looking for some advice. I want to build a text editor where git history is displayed as first class files directly in the file tree. Like a page named landing.html would have landing.html.v0, landing.html.v1, landing.html.v2, etc. directly as regular files. With maybe the git commit message also in the file name for more context. What would be the best way to make this happen? Build an app from scratch with somethin…

Get Emacs and Neotree[1] and start hacking. You'll learn a Lisp, and you'll have a working demo in under a week.

[1] https://github.com/jaypei/emacs-neotree

Re: Xray – An experimental next-generation Electron-based text editor

#217
post #2

A higher performance backend with the undeniable community momentum that Atom has? I want this to work. Also excited to see the discussion and possible cross-pollination with Xi[1] and raphlinus. [1] https://github.com/google/xi-editor

xi editor, when i tried it, would crash upon opening minimised css of fontawesome A 3 line file, be it long lines, shouldn't happen

> A 3 line file, be it long lines, shouldn't happen

No. It should not.

But that’s completely unfair. Xi does not even claim to be beta. I haven’t touched it in months. But when I did, it was a good (start of) a Mac frontend that was clearly not finished.

The only people I imagine using it now probably use it to dogfood the backend and piece together a solid plugin API.

I would prefer Xi-style win the mind share. Native front ends that tie to a common solid backend that a large community can share to build strong plugin support.

I’ll settle for xray-style, a better cross-platform frontend that doesn’t redraw large portions of the DOM quite so often. Javascript is fast enough. A good (heh) extension language. The drawing layer is what makes Electron a slow, bloated choice for a text editor.

Since Atom came out, I have had a backgrounded dream that once things settled, they would write a faster front end for the text. But that is difficult to do if your API is “can you do it in the DOM with javascript?

But they are atom.io. They can change their API if they need to.

VS Code, with its well-bounded API is a much better candidate. And I would love to be surprised by a Microsoft skunkworks non-Electron release.

Xi, is a solid idea. Don’t know if they can build a community out of nothing. I am worried that an API of ”here is a JSON firehose, hook up whatever you want to it” will fragment the backend.

I think Xi would be well served by saying “Here is your firehose, but, the official way is our VS Code emulation plugin.” Or something solid and well-defined.

It is unclear where Xi is going so far, that may happen.

Re: Xray – An experimental next-generation Electron-based text editor

#218

Earlier quoted context omitted.

Yeah, I wonder about how this Rust thing is going to work. I had always thought that the Atom perf problems didn't come from the underlying language but from the fact that it basically creates a massive DOM for every document... so how much is changing the backend language going to achieve?

> it basically creates a massive DOM for every document From the OP: > In Atom, the vast majority of computation of any given frame is spent manipulating the DOM, recalculating styles, and performing layout. To achieve good text rendering performance, it is critical that we bypass this overhead and take direct control over rendering. Like Alacritty and Xi, we plan to employ OpenGL to position quads that are mapped to…

I can't wait for my editor to get a Vulkan backend, for the utmost in text editing performance.

Re: Xray – An experimental next-generation Electron-based text editor

#219
post #217

Earlier quoted context omitted.

xi editor, when i tried it, would crash upon opening minimised css of fontawesome A 3 line file, be it long lines, shouldn't happen

> A 3 line file, be it long lines, shouldn't happen No. It should not. But that’s completely unfair. Xi does not even claim to be beta. I haven’t touched it in months. But when I did, it was a good (start of) a Mac frontend that was clearly not finished. The only people I imagine using it now probably use it to dogfood the backend and piece together a solid plugin API. I would prefer Xi-style win the mind share. Nati…

oh yeah, i will give xi another chance, what it didn't crash on it reacted nicely and fast. But no reason to trade in my sublime text yet :)

Re: Xray – An experimental next-generation Electron-based text editor

#220

Earlier quoted context omitted.

YES YES what prefs changes were these? Please share!

Don't have exact URL, but google 'windowserver high CPU'. Fixing windowserver fixed FF too.

Interesting. Some kind of animation/repainting thing? This bug[1] seems to be along those lines.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1404042

Post reply on HN