Could 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?
Look at ropes - https://en.wikipedia.org/wiki/Rope_(data_structure)
Show HN: Lite – A small, fast text editor
131–140 of 276 posts
Re: Show HN: Lite – A small, fast text editor
#132Earlier quoted context omitted.
Can you make WASM apps using js toolkits that compiles to native desktop yet? Seems like that will be a huge step forward from electron apps.
Sure, as native as any language that runs in a VM. There is no reason a WASM app can or can't be any more or less native than something running on lua (like in this case), jvm or anything else. People don't use Electron to get a js runtime, they use it to get a web-like runtime. Any javascript (including WASM) app can run without electron in either node or in the bundled runtimes that OSX/Windows/Gnome/Whatever has,…
So, obviously, "native" is a spectrum. On OS X, Cocoa > QT > Java > Wine > Docker + X11 forwarding.
But one thing I think is being missed here is that Lua, Python, and other scripting languages are just a lot more resource efficient than electron, in terms of runtime size, memory usage, cpu usage, etc. A very highly optimized Electron app like VS Code might outperform a more run-of-the-mill Lua app, but that's an outlier.
Re: Show HN: Lite – A small, fast text editor
#133Something similar is Revery, written in ReasonML (OCaml) [0].
I saw some comments here about a WASM renderer-based editor, I think there is something in Flutter that is similar, where Flutter uses Skia to render its components.
Re: Show HN: Lite – A small, fast text editor
#134Looking at the screenshot in full size [1], it looks really cool but the text is visibly blurry (look at the = signs for example). Text rendering is hard, and especially for a text editor it's a good idea to just use the current platform's text rendering instead of rolling your own. Of course SDL "rolls its own" because it focuses on being exactly the same on every platform. SDL seems to offer font hinting which woul…
SDL has hinting because it uses freetype. But this program doesn't use that. It uses stb_truetype which does not support hinting.
Re: Show HN: Lite – A small, fast text editor
#135Earlier 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...
> virtual DOM implies DOM existence
No, it doesn't. I addressed this in the comment above. React's virtual DOM has been used to render:
- Plain HTML (e.g. server-side rendering) - Native UI framework objects (e.g. React Native) - Text-based interfaces (e.g. Ink) - Smart TV devices (e.g. Netflix's Gibbon) - Browser `` elements - Markdown formatted text
And a whole bunch of other targets.
> DOM based systems use so called retained mode rendering. But this one uses something that can be classified as immediate mode rendering.
This seems orthogonal to the question? I'm not trying to be difficult, I sincerely don't understand why this would mean the two are "not even close".
Re: Show HN: Lite – A small, fast text editor
#136Firstly, let me say that I'm in no way hating on Lite, these are just some fact-based observations. Thought I'd give this a quick try on my Windows machines, where my liteweight editor of choice is Notepad3. A fresh start of Lite uses 10MB of memory, vs 3MB for Notepad3. After opening a 27.5MB text file in each, Lite used 156MB of memory, vs 68 for Notepad3. The functionality available in Notepad3 is also vastly supe…
The memory usage can be explained by what structure it uses for its buffer. It is a Lua table of lines. It is this splitting of the file into lines that causes the larger memory usage due to internal fragmentation.
Re: Show HN: Lite – A small, fast text editor
#137Firstly, let me say that I'm in no way hating on Lite, these are just some fact-based observations. Thought I'd give this a quick try on my Windows machines, where my liteweight editor of choice is Notepad3. A fresh start of Lite uses 10MB of memory, vs 3MB for Notepad3. After opening a 27.5MB text file in each, Lite used 156MB of memory, vs 68 for Notepad3. The functionality available in Notepad3 is also vastly supe…
[deleted]
Re: Show HN: Lite – A small, fast text editor
#138Firstly, let me say that I'm in no way hating on Lite, these are just some fact-based observations. Thought I'd give this a quick try on my Windows machines, where my liteweight editor of choice is Notepad3. A fresh start of Lite uses 10MB of memory, vs 3MB for Notepad3. After opening a 27.5MB text file in each, Lite used 156MB of memory, vs 68 for Notepad3. The functionality available in Notepad3 is also vastly supe…
[deleted]
Re: Show HN: Lite – A small, fast text editor
#139Earlier quoted context omitted.
Sure, as native as any language that runs in a VM. There is no reason a WASM app can or can't be any more or less native than something running on lua (like in this case), jvm or anything else. People don't use Electron to get a js runtime, they use it to get a web-like runtime. Any javascript (including WASM) app can run without electron in either node or in the bundled runtimes that OSX/Windows/Gnome/Whatever has,…
So, obviously, "native" is a spectrum. On OS X, Cocoa > QT > Java > Wine > Docker + X11 forwarding. But one thing I think is being missed here is that Lua, Python, and other scripting languages are just a lot more resource efficient than electron, in terms of runtime size, memory usage, cpu usage, etc. A very highly optimized Electron app like VS Code might outperform a more run-of-the-mill Lua app, but that's an out…
Actually, for a while Java was just below Cocoa for "nativeness" the LAF for it was maintained by Apple itself.
Re: Show HN: Lite – A small, fast text editor
#140Earlier quoted context omitted.
So, obviously, "native" is a spectrum. On OS X, Cocoa > QT > Java > Wine > Docker + X11 forwarding. But one thing I think is being missed here is that Lua, Python, and other scripting languages are just a lot more resource efficient than electron, in terms of runtime size, memory usage, cpu usage, etc. A very highly optimized Electron app like VS Code might outperform a more run-of-the-mill Lua app, but that's an out…
Actually, for a while Java was just below Cocoa for "nativeness" the LAF for it was maintained by Apple itself.
I'd heard that before! I kind of debated whether to put Java or QT first—it came down to the fact that QT apps just feel closer to me on macOS. Although I don’t know how ugly they are under the hood.
Edit: What does LAF stand for?