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

Show HN: Lite – A small, fast text editor

github.com

Post reply on HN
Print view View original

121–130 of 276 posts

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

#121

Post by c-smile »

eyelidlessness wrote: post #111
c-smile wrote: post #101

Earlier quoted context omitted.

Not even close.

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...

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

#122

Post by SahAssar »

rhlsthrm wrote: post #107
nwienert wrote: post #82

Earlier quoted context omitted.

You seem to be the one drawing the line saying Electron isn’t vs something like this is. Is a WASM app that renders to WebGL native? I guess the point is native should probably mean “using the toolkit the OS provides” and we should just use “performant” in most cases.

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, but the point of electron isn't to write JS, it's to write web-like code. For that it requires a browser in a predictable version, which is what electron gives you (albeit at a high cost.)

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

#123

Post by kingosticks »

akavel wrote: 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…

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

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

#124

Post by ubercow13 »

c-smile wrote: post #80
joan_kode wrote: post #50

Looking 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…

Yes, the rendering implementation uses gray-scale antialiasing. But system uses ClearType - compare rendering in window caption (rendered by Windows) and the text inside client area. Gray-scale may work on high-DPI monitors, but on typical monitors it will be blurry. But Apple and Microsoft still use ClearType even on high-dpi monitors. For that matter, Sublime Text, that uses similar architecture (but Python instead…

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-...

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

#125

Post by tambourine_man »

rxi wrote: post #35
tambourine_man wrote: post #20

So there's no GUI toolkit? Everything is drawn with Simple DirectMedia Layer?

Not even that: SDL just provides a pixel buffer, the application draws everything itself per-pixel. Lite uses a technique I refer to as "cached software rendering" which allows the application code to be written as if it's doing a fullscreen-redrawn when it wants to update, the renderer cache (rencache.c) then works out which regions actually need to be redrawn at the end of the frame and redraws only those. You can…

> …the application draws everything itself per-pixel

That’s what I meant, yes. Interesting approach and impressive.

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

#126

Post by seddin »

joan_kode wrote: post #50

Looking 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…

I have just downloaded it too and witnessed this issue, the text looks weird, like a little bit blurry, it would be perfect if it looked like on Sublime Text 3 or on this image https://i.ibb.co/qYCpx3x/1588859182372.gif

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

#127

Post by stOneskull »

david_draco wrote: post #32
rfeague wrote: post #18

Since 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?

What would you say are top open source editors one would consider, and by what criteria should one benchmark the comparison? While subjective criteria are perhaps most important (usability, integration with favorite programming language, extensibility), for technical quality perhaps there can be some meaningful numerical benchmarks. For example, the lag and memory use when opening a many-GB text file and editing the…

Personally, I'm thinking of its comparison to Geany. A wonderful editor but I have a feeling the first difference is it's going to seem real bloated. Time to see.

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

#128

Post by stefanos82 »

vijaybritto wrote: post #49
rfeague wrote: post #18

Since 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…

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.

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

#129

Post by chrisseaton »

c-smile wrote: post #80
joan_kode wrote: post #50

Looking 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…

Yes, the rendering implementation uses gray-scale antialiasing. But system uses ClearType - compare rendering in window caption (rendered by Windows) and the text inside client area. Gray-scale may work on high-DPI monitors, but on typical monitors it will be blurry. But Apple and Microsoft still use ClearType even on high-dpi monitors. For that matter, Sublime Text, that uses similar architecture (but Python instead…

> But Apple and Microsoft still use ClearType even on high-dpi monitors.

This isn't true.

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

#130

Post by SahAssar »

rubber_duck wrote: post #61
metalliqaz wrote: post #58

Earlier quoted context omitted.

That could possibly be a result of the image compression as well, no?

Shouldn't PNG be lossless by default ? (you could do some lossy pass to optimise but in that case you're probably better off using JPEG ?)

Sites like github often "optimize" images to lower bandwidth costs. Basically any platform you share images on that is at scale will probably re-compress images. For PNG they often reencode the image in a lossy way.
Post reply on HN