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

101–110 of 276 posts

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

#101

Post by c-smile »

eyelidlessness wrote: post #76
rxi wrote: post #35

Earlier quoted context omitted.

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…

Sounds like the pixel grid equivalent of a "virtual DOM"?

Not even close.

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

#102

Post by thomasqm »

samtheprogram wrote: post #78
cwyers wrote: post #71

Earlier quoted context omitted.

It's written in Lua and doesn't use the OS GUI APIs and widgets anywhere. I'm not sure I understand what makes this more "native" than Javascript.

There’s way less abstraction going on in Lua app that has a hand-rolled GUI versus an app built on top of a web browser like Electron. Hand rolling you’re own UI doesn’t make it less native — is Ableton Live not-native? Or are you drawing the line because Lua is a scripting language?

Yep, it’s not Win32, it is a software renderer (according to renderer.c).

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

#103

Post by LukeShu »

devy wrote: post #86

Checking the Github repo, it says 92.3% C[1], 2.6% Lua[2], why does the author claim it's a "text editor written in Lua" instead? [1]: https://github.com/rxi/lite/search?l=c [2]: https://github.com/rxi/lite/search?l=lua

Because it has complete copies of Lua 5.2 (src/lib/lua52), stb truetype (src/lib/stb), and SDL2 (winlib/SDL2-2.0.10) checked in.

Excluding those, it's 1369 lines of C (.c or .h), and 5389 lines of Lua (.lua), and 112 lines of other files (license, readme, build scripts...); or 78.4% Lua, 19.9% C, and 1.6% other. I didn't count fonts or images (.ttf, .ico, or .inl).

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

#104

Post by ubercow13 »

paulie_a wrote: post #95
cwyers wrote: post #71

Earlier quoted context omitted.

It's written in Lua and doesn't use the OS GUI APIs and widgets anywhere. I'm not sure I understand what makes this more "native" than Javascript.

Because JavaScript is not a native language.

Neither is Lua

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

#105

Post by cwyers »

paulie_a wrote: post #95
cwyers wrote: post #71

Earlier quoted context omitted.

It's written in Lua and doesn't use the OS GUI APIs and widgets anywhere. I'm not sure I understand what makes this more "native" than Javascript.

Because JavaScript is not a native language.

I mean, yes, Javascript isn't x86 assembly code, but neither is Lua. Sure, Javascript was designed to be embedded within other applications, but so was Lua. And neither _has_ to be. People seem to be using "native" to mean "lightweight" or "performant," but if that's what they mean, they should just use those words.

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

#107

Post by rhlsthrm »

nwienert wrote: post #82
samtheprogram wrote: post #78

Earlier quoted context omitted.

There’s way less abstraction going on in Lua app that has a hand-rolled GUI versus an app built on top of a web browser like Electron. Hand rolling you’re own UI doesn’t make it less native — is Ableton Live not-native? Or are you drawing the line because Lua is a scripting language?

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.

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

#108

Post by userbinator »

GordonS wrote: post #96

Firstly, 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…

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 to test with, but a 6.5MB one takes 17MB when loaded. In other words, the expansion factor is close to Notepad3.)

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

#109

Post by pankajdoharey »

cwyers wrote: post #71
mmm_grayons wrote: post #56

This is a very nice piece of work, and I think very important: it shows that it's very much possible to make slick interfaces without using javascript/web technologies. It's also just as hackable as something like vscode or vim. I hope there's a shift back to native or semi-native applications as opposed to web-based stuff. It's certainly not perfect yet (it has some scaling/rendering issues and is slow to open large…

It's written in Lua and doesn't use the OS GUI APIs and widgets anywhere. I'm not sure I understand what makes this more "native" than Javascript.

If you look at the source its not Lua its, pretty much small amounts of C to embed Lua, the renderer is a SDL renderer in C. Its a pretty decent architecture I have been toying with a similar idea past few days with C + chez scheme + SDL.

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

#110

Post by rplnt »

lykr0n wrote: post #63
mmm_grayons wrote: post #56

This is a very nice piece of work, and I think very important: it shows that it's very much possible to make slick interfaces without using javascript/web technologies. It's also just as hackable as something like vscode or vim. I hope there's a shift back to native or semi-native applications as opposed to web-based stuff. It's certainly not perfect yet (it has some scaling/rendering issues and is slow to open large…

I 100% agree with you, but the R&D time for something like this would eclipse an equivalent effort in Javascript/web tech. There needs to be focus on building tooling that enables rapid development of native applications. GTK is a good example. Glade is a perfectly fine editor, but the underlying tooling for GTK is a mixed bag.

The time and resources users waste on using such application eclipses the difference in development. One could be folding enzymes instead of waiting for syntax highlighting to finish rendering in vs code.
Post reply on HN