Earlier quoted context omitted.
On my GNU / Debian testing 64-bit, with 10 tabs opened it consumed 31 MiB of RAM and my CPU pushed itself to reach 0.75% at its busiest processing during typing. To me this is simply mind-blowing.
Not as mind-blowing as SublimeText leaking 3 solid GB of RAM after a few days on my Debian..
Show HN: Lite – A small, fast text editor
241–250 of 276 posts
Re: Show HN: Lite – A small, fast text editor
#242Could you share what data structure you use to keep the text in? I'm curious how text editors work, since you need fast inserts anywhere, is the text a linked list?
My Lua isn't strong, but I think this is what you're looking for: Data structure initialization: https://github.com/rxi/lite/blob/master/data/core/doc/init.l... How insertion works here, which illuminates how the table is used: https://github.com/rxi/lite/blob/143f8867a13a35f5688ad7c9771...
There's a good post on the Visual Studio Code blog about why and when they moved on from an array of lines to a new structure based on a piece table.
https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
Re: Show HN: Lite – A small, fast text editor
#243Earlier quoted context omitted.
Yes, and there is no reason you can't have a cow as a pet because they have pointy ears and a tail, like cats. It seems you've lost your way, my friend.
Why is using JS or WASM as a building block for a app any worse than lua, python or ruby? What is the material difference?
Re: Show HN: Lite – A small, fast text editor
#244One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not. What are they talking about!? I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over doub…
you may find this interesting: "Why are 2D vector graphics so much harder than 3D?" https://blog.mecheye.net/2019/05/why-is-2d-graphics-is-harde...
Admittedly, not a 2D text engine, but I keep up with the research.
The difference between the blog post you linked and a programmer's text editor is night & day.
There's a huge difference between arbitrary 2D graphics and fixed-width text rendering. The former has crazy complex corner-cases, and also has to deal with all of the fun things 3D engines do such as arbitrary transformations and transparency.
A web browser has to deal with the arbitrary case, which is why Firefox's new Rust-based renderer took so many years of hard work to write. It's a complex beast.
A fixed-width text editor is more or less just putting sprites on a grid. Sure, there's subpixel alignment, antialiasing, and maybe even ligatures, but this is nothing really in comparison. They're all "local" issues where typically at most a few hundred pixels are affected per character update.
Or to put it another way, text editor rendering is "embarrassingly parallel". The screen can be split up into lines or char blocks and each can be drawn separately and updated individually when modified.
Compare this to 3D games that are pumping out 4K pixels every frame, updating all of them every time. Web browsers do the same thing, they have to update the entire screen every frame in a lot of scenarios and can manage this at 60 Hz too. Firefox and Chrome both can do this now for much more complex scenarios than text editing.
Re: Show HN: Lite – A small, fast text editor
#245One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not. What are they talking about!? I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over doub…
I dunno why you haven't encountered it, but it's a real thing. I remember using one editor perhaps 8 years ago, and if I tried multi-cursor mode with more than ~40 insertion points (totally reasonable to edit 40 similar lines at a time), it took a couple of seconds to register each keypress. Similarly, other editors wind up choking on syntax highlighting, or large files, or find & replace, or documentation lookup, or…
Notably, they're all Windows native apps written in C++, with the exception of VS Code, which is partially JavaScript.
I've noticed that some of them struggle with huge (1 GB) files, but editing such as large file is a somewhat strange thing to do.
Re: Show HN: Lite – A small, fast text editor
#246Since there are a lot of text editors, I'd like to see more detail on the motivations for yet another one. How does this compare to the current top-five open source editors?
The resident memory was 10MB in my windows machine when I ran this. A strong reason for me to use this would be in a low powered device. I want to write markdown in a tiny editor like this. I want to run multiple projects side by side and this is good for that. If I'm a beginner trying do dev on a machine lower than 4G of RAM. So many more examples come to my mind. I'm pretty sure there are more Also the immediate UI…
Re: Show HN: Lite – A small, fast text editor
#247One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not. What are they talking about!? I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over doub…
While the reason could easily be that not everyone has the horsepower you're used to (I assume 60FPS at 4K requires a certain level of hardware), people often mean something other than high speed when they say "snappy": ease of use, good descriptive UI that gives you feedback on actions and their results, certain features that simplify tasks such as integration with other tools (git compilers, etc.). Also add other f…
I really like the new VS Code remote-editing feature, where the GUI is local but you can work directly on the remote system.
Visual Studio has a vaguely similar "remote debugger" feature.
Generally I avoid remote development like the plague. As you said, the latency is quite noticeable through any kind of remote connection.
Pro tip for anyone using Windows: Modern versions limit RDP to 30Hz by default, irrespective of CPU power or available bandwidth. See this MS article on how to remove the limitation: https://support.microsoft.com/en-au/help/2885213/frame-rate-...
I always set this to 60 Hz on high-performance "workstation" VDI systems used by developers.
Re: Show HN: Lite – A small, fast text editor
#248One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not. What are they talking about!? I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over doub…
Re: Show HN: Lite – A small, fast text editor
#249Earlier quoted context omitted.
GitHub doesn’t “optimize” your images, just as it doesn’t format your code. People would storm the barricades if Github changed their files.
They do change files that are embedded in readmes, just like most web platforms do. The original file is unchanged, but the version embedded in the readme preview on github.com is changed.
Re: Show HN: Lite – A small, fast text editor
#250One thing that has mystified me is all these people talking about text editor responsiveness, whether it feels "snappy" or not. What are they talking about!? I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over doub…
> The exception is Microsoft Word, which does about 30Hz and I hate this, but it's a shitty WYSIWYG editor Was the shitty there qualifying WYSIWYG (as in WYSIWYG editors are definitionally shitty) or qualifying MS Word (as in MS Word is a shitty editor)? If the latter, do you have suggestions for good WYSIWYG editors?
I write a lot of reports these days, and the Word editor interface drives me crazy. Like I said, it's slow, irrespective of the hardware. It can't even maintain a consistent 30 Hz on a high-end gaming rig when editing plain-text paragraphs with no special formatting. I suspect it's throttled internally, but it could just be badly written.
The editor is also very glitchy in the way it handles formatting. Lots of little annoyances just haven't been fixed and have been left there to fester for decades. It's all too easy to corrupt a document's styles to the point that the only reasonable fix is to carefully cut & paste all content into a new document, going through Notepad on the way to guarantee all hints of the original formatting are stripped.