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.
Xray – An experimental next-generation Electron-based text editor
211–220 of 240 posts
Re: Xray – An experimental next-generation Electron-based text editor
#212Earlier 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.
Re: Xray – An experimental next-generation Electron-based text editor
#213Earlier 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..
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
#214Earlier 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.
Re: Xray – An experimental next-generation Electron-based text editor
#215Earlier 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+
Re: Xray – An experimental next-generation Electron-based text editor
#216Looking 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…
Re: Xray – An experimental next-generation Electron-based text editor
#217A 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
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
#218Earlier 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…
Re: Xray – An experimental next-generation Electron-based text editor
#219Earlier 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…
Re: Xray – An experimental next-generation Electron-based text editor
#220Earlier 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.