Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

161–170 of 240 posts

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

#161

Post by _pmf_ »

hartator wrote: post #154

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…

Eclipse's abstract/generic VCS interface is pretty nice to use and there's a nice virtual file system layer that makes reifying the history of a file as distinct entries pretty straight forward, but Eclipse is a taboo in the modern ecosystem of half-assedness. (Plus I admit that there's somewhat of a learning curve to the PDE.)

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

#162

Post by dkns »

Prefinem wrote: post #48
PrimHelios wrote: post #42

Earlier quoted context omitted.

That sounds like an OS/hardware problem, honestly. There's no reason vim with any setup should lock up a machine.

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

#163

Post by zaarn »

codedokode wrote: post #76
stouset wrote: post #34

Earlier quoted context omitted.

Hardware acceleration of rendering is more energy-efficient and less resource intensive than CPU-based software rendering.

Is it really so? Can OpenGL update only a small part of a framebuffer (for example, when a single letter is typed) or will it rerender the whole text?

Depends on how you render.

I've written a OpenGL engine for a university course that use partial frame updates to reduce the number of redraws per frame.

IIRC the partial rerender variant was about 3 times faster than the full render.

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

#164

Post by bitcoinboi9 »

codedokode wrote: post #76
stouset wrote: post #34

Earlier quoted context omitted.

Hardware acceleration of rendering is more energy-efficient and less resource intensive than CPU-based software rendering.

Is it really so? Can OpenGL update only a small part of a framebuffer (for example, when a single letter is typed) or will it rerender the whole text?

If done in a smart way, of course you can. Similar thing with canvas. If letter/word spacing depends on that character, then you'd probably need to rerender more stuff.

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

#165

Post by blt »

paultopia wrote: post #107
rukuu_001 wrote: post #94

Earlier quoted context omitted.

Are you on a Mac? Had same, but fixed it with some prefs changes. Before that FF was stuck at 8-10% CPU.

YES YES what prefs changes were these? Please share!

It is also happening to me. Big CPU usage spikes for no apparent reason. Sucks because I'm trying to reduce dependence on Google.

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

#166

Post by zuzun »

asimpletune wrote: post #45

Why doesn’t someone make a better native editor? (That’s not sublime)

People that have these skills realize that similar to Greenspun's Law:

> Any sufficiently complicated program with an extensible cross-platform GUI contains an ad-hoc, informally-specified, bug-ridden implementation of half of a webrowser.

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

#167

Post by netzone »

avhon1 wrote: post #158
krisroadruck wrote: post #71

Earlier quoted context omitted.

Im probably super out of the loop but I always wonder about these kind of comments. Even if electron uses say 500% more resources than vim, why in the world would that matter beyond personal irritation for anyone making 6 figs doing software development? I get the impression from these arguments that people are trying to do serious software development on 5 year old budget hardware. In any profession, investing in yo…

> Most of the geeks I know have far more machine than they could ever use as a matter of pride. I take the opposite approach: I really enjoy using hardware which is exactly adequate to what I need it to do. My entire senior year (2016-2017) of college, I ran Arch linux on an IBM Thinkpad X40 that I bought on eBay for 30 USD. It had a 1.1 GHz 32-bit Pentium 4, 1 GB of memory, a 32 GB CompactFlash card as a hard drive,…

What's stopping you from using the software you've listed on a more modern laptop? I mean, I don't really understand the point of "cooperating with the system". You found a setup that works nicely for you, with a newer laptop everything would be faster, you could run Quake 3 without lag.

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

#168

Post by AstralStorm »

stephenr wrote: post #100
krisroadruck wrote: post #71

Earlier quoted context omitted.

Im probably super out of the loop but I always wonder about these kind of comments. Even if electron uses say 500% more resources than vim, why in the world would that matter beyond personal irritation for anyone making 6 figs doing software development? I get the impression from these arguments that people are trying to do serious software development on 5 year old budget hardware. In any profession, investing in yo…

Most laptops top out at 16GB of ram. Unless you’re only using your editor, you need resources for other things too. VM based dev environments via vagrant, docker etc are very common. What I don’t understand is why if you’re going to use an editor that’s resource heavy, you wouldn’t just use an IntelliJ product. Sure, they’re jvm based and “heavy”. But they’re also fucking amazing, and have functionality none of these…

IntelliJ tends to eat gigabytes per instance. This is not good enough when you want to have just even 2 projects open... That id's with a tweaked JVM.

It alongside Java compilation can bring a machine with 10 GB free ram to its knees and end in swap death.

I deal daily with the variant called Android Studio. Enough that about 30% I'd the coding has to be done in vim for performance reasons.

The only great features are refactoring, advanced syntax highlighting, code completion and advanced search...

If someone wrote something that is not a hog and can handle Android flavor of C++ and Java as well I'd switch in a heartbeat.

This Xray is not it.

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

#169

Post by pasta »

paulryanrogers wrote: post #81
zero_iq wrote: post #46

Earlier quoted context omitted.

I always think back to when I had a 120MB hard disk in the early 90s. It contained multiple editors, raytracers, games, music editors + music, images, paint programs, multiple programming languages and development kits, a multi-tasking operating system... and room to spare. 90s me would be absolutely floored by a text editor needing 438MB RAM. Wait, what am I saying? 2018 me is pretty flabbergasted by it, but perhaps…

My rose-tinted glasses are cracked, so I don't want to go back. Software was a lot less capable back then. And APIs were often incredibly obtuse, bespoke, or both.

"Software was a lot less capable back then"

I think this is true-ish.

But when I compare Blender (330MB) and 3ds Max (6GB) I got the feeling some software is just better constructed.

Using a web browser as a text editor might not be the best solution...

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

#170

Post by stephenr »

AstralStorm wrote: post #168
stephenr wrote: post #100

Earlier quoted context omitted.

Most laptops top out at 16GB of ram. Unless you’re only using your editor, you need resources for other things too. VM based dev environments via vagrant, docker etc are very common. What I don’t understand is why if you’re going to use an editor that’s resource heavy, you wouldn’t just use an IntelliJ product. Sure, they’re jvm based and “heavy”. But they’re also fucking amazing, and have functionality none of these…

IntelliJ tends to eat gigabytes per instance. This is not good enough when you want to have just even 2 projects open... That id's with a tweaked JVM. It alongside Java compilation can bring a machine with 10 GB free ram to its knees and end in swap death. I deal daily with the variant called Android Studio. Enough that about 30% I'd the coding has to be done in vim for performance reasons. The only great features ar…

> IntelliJ tends to eat gigabytes per instance

Mine is currently sitting at 1.7GB with 3 projects open, but yes it does use a lot of memory. I never argued that it doesn't, but as you point out:

> great features are refactoring, advanced syntax highlighting, code completion and advanced search

Syntax highlighting and search are common these days, code completion is in most decent editors/IDE's but the key one is refactoring, and it's associated tools: find usage.

I keep trying out KomodoIDE (still not really native, but at least it's not Java) hoping it will be good enough to change to, and it hasn't gotten there yet.

> If someone wrote something that is not a hog and can handle Android flavor of C++ and Java as well I'd switch in a heartbeat.

The problem for me I think, is language/tool support in general. I generally write in scripting/interpreted languages (although I have written Java for a client) but it could be shell, php, python, ruby, sql, or of course any number of 'data' formats - json, xml, markdown, yaml (if Im feeling masochistic that day).

Post reply on HN