Live data from Hacker News

Show HN: Lite – A small, fast text editor

github.com

181–190 of 276 posts

Re: Show HN: Lite – A small, fast text editor

#181

Earlier quoted context omitted.

I'm open to the possibility that I'm that wrong in my understanding, but this didn't help me understand any better at all. The technique does sound similar to me. Both (as I understand it) maintain a representation in memory of the final rendering and use a diff to determine which parts of the rendering to perform. The "virtual DOM" technique isn't strictly tied to a browser DOM, though the term is a reference to tha…

virtual DOM implies DOM existence. DOM based systems use so called retained mode rendering. But this one uses something that can be classified as immediate mode rendering. Check https://docs.microsoft.com/en-us/windows/win32/learnwin32/re...

A virtual DOM doesn't necessarily imply DOM existence; I don't buy that. It really depends on how persistent you want your "virtual" to be.

A virtual DOM, to me, means that the application renders by, every time, constructing data structures which are handed off to be reconciled with the display.

If, as in an HTML application, you render by means of a retained mode real DOM, then the reconciliation is via comparison of the virtual with the real. But that's not the only way to handle the output of the construction of a virtual DOM; it could figure out how those structures intersect with the dirty rectangle/s, and only render the subtree of the DOM which applies.

rxi's technique resembles a virtual DOM of depth 2 (1 root and everything is a child) and absolute positioning, though it's even closer to an OpenGL display list or combined vertex & command buffer. For that reason, I think it's a little bit of a stretch; not on the virtual DOM angle, but on the not particularly DOM-like nature of the drawing commands.

Re: Show HN: Lite – A small, fast text editor

#182

Earlier quoted context omitted.

texadept is great, it can handle really large files where most other editors crash/die.

Just tested that premise with a 300MB text file... Kate loaded it no problem in about 3secs... textadept didn't load the file, gave an error. From textadepts FAQ: Q: Why can’t Textadept handle HUGE files very well? A: Textadept is an editor for programmers. It is unlikely a programmer would be editing a gigantic log file. There are other tools for that case.

I can't speak to the FAQ, I guess by 'gigantic' they mean tens of GBs. I use it for what i consider large files all the time, I just opened a 2GB file to check I am not going mad and it worked just fine. It took around 10 seconds to open so I agree it's not the quickest to start but at least it does. I'm running Textadept 10.7 on a decent Linux machine.

Re: Show HN: Lite – A small, fast text editor

#183

Earlier quoted context omitted.

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…

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.

We used to be able to open 10 files at a time on 4MB systems back in the 90s.

(They weren't big files, of course, but still. Standards have slipped.)

Re: Show HN: Lite – A small, fast text editor

#184
post #118

Earlier quoted context omitted.

Lite has a slightly smaller binary, however; but as someone whose regular text editor on Windows is notepad (the stock one, which is 1MB rather disappointing. I do realise that both Lite and Notepad3 are significantly more featureful, but I'm not sure if the increase in resource consumption is proportional. (For comparison, regular notepad uses <1MB of memory when holding nothing, and I don't have a 27.5MB text file…

Notepad is basically a wrapper around a text box provided by the Windows native UI libraries. The binary is so small because the heavy lifting (such as there is any to be done in Notepad) is handled by the platform.

Precisely. And for the same reason, Windows 95 could only edit 64kb of text in Notepad because that was the most text that could be put in an EDIT control.

Re: Show HN: Lite – A small, fast text editor

#185
post #179
post #99

Earlier quoted context omitted.

That's not anyhow different from typical GDI, CoreGraphics, GTK/Cairo way of doing rendering. Windows, MacOS and GTK maintain internal pixmap buffer for a window. And when needed you call InvlidateRect(wnd,rc) and receive WM_PAINT with cumulative rect to update. Personally, I would create an abstraction that wraps couple of functions of GDI, CoreGraphics and Cairo and use it instead manual pixmap rendering. Will be f…

Interesting. Do you know any software whose source code is available that uses such an abstraction to paint the screen?

Any classic Windows, MacOS or GTK application does that.

Check https://docs.microsoft.com/en-us/windows/win32/learnwin32/pa...

If your question is about unified wrapper for multiple platforms then wxWidgets will qualify : https://wiki.wxwidgets.org/Painting_your_custom_control

As my Sciter where I wrapped Direct2D/DirectX, Skia/OpenGL, CoreGraphics, Cairo, GDI+ into class graphics abstraction so rest of code is isolated from particular paltform/backend used: https://github.com/c-smile/sciter-sdk/blob/master/include/be...

Re: Show HN: Lite – A small, fast text editor

#186

Earlier quoted context omitted.

virtual DOM implies DOM existence. DOM based systems use so called retained mode rendering. But this one uses something that can be classified as immediate mode rendering. Check https://docs.microsoft.com/en-us/windows/win32/learnwin32/re...

A virtual DOM doesn't necessarily imply DOM existence; I don't buy that. It really depends on how persistent you want your "virtual" to be. A virtual DOM, to me, means that the application renders by, every time, constructing data structures which are handed off to be reconciled with the display. If, as in an HTML application, you render by means of a retained mode real DOM, then the reconciliation is via comparison…

> A virtual DOM doesn't necessarily imply DOM existence;

That's wrong. virtual DOM is always a parallel structure to real DOM - projection of it. That's by definition of it.

From vDOM authors: https://reactjs.org/docs/faq-internals.html

> The virtual DOM (VDOM) is a programming concept where an ideal, or “virtual”, representation of a UI is kept in memory and synced with the “real” DOM

Re: Show HN: Lite – A small, fast text editor

#187

Earlier quoted context omitted.

Apple removed all subpixel antialiasing on Mojave [1] and on Windows it isn't used for any 'modern' app using UWP onwards afaik [1] https://arstechnica.com/features/2018/09/macos-10-14-mojave-...

well, apple certainly de-emphasized subpixel antialiasing. i am still using a non-retina monitor for all of my day-to-day work. when i first installed mojave, it made my display look so bad that it gave me headaches. so i wiped my mac entirely and re-installed the previous version of macos. later, i learned that subpixel anti-aliasing is still there, it just takes some fiddling to get it back. https://www.howtogeek.c…

I just purchased an HP Z27 (4K 27”) because I couldn’t deal with the low-res monitors I had at home. The high quality monitors in my office had really spoiled me.

I’m so glad I did. Night and day difference.

Re: Show HN: Lite – A small, fast text editor

#188
post #4

If you are interested in small Lua-based text editors, I advise you to take a look at Textadept: https://foicica.com/textadept/ . Specifically as to minimalism: "Relentlessly optimized for speed and minimalism over the years, the editor consists of less than 2000 lines of C code and less than 4000 lines of Lua code." I believe this is a limit that the editor's author self-imposed and keeps to it with an impressive st…

Textadept is great. It's my daily driver. That's mostly because I was looking for something lightweight that I could configure to operate similarly on windows and mac.

Re: Show HN: Lite – A small, fast text editor

#189

Earlier quoted context omitted.

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…

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.

Wut, I opened 12 files in 9MB back in the day on a 32MB device as nothing.

Re: Show HN: Lite – A small, fast text editor

#190

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.

We used to be able to open 10 files at a time on 4MB systems back in the 90s. (They weren't big files, of course, but still. Standards have slipped.)

Yes, those were the days...every once in a while, I visit https://kolibrios.org/en/screen to get nostalgic.

Indeed standards have slipped or better say have been sacrificed at the altar of "quantity over quality".

For a simple "Hello, World!" string message, nowadays you need how many MBs of RAM.

Madness, complete madness!

Post reply on HN