Live data from Hacker News

Show HN: Lite – A small, fast text editor

github.com

71–80 of 276 posts

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

#71

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.

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

#72

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…

If you compare the SDL-rendered text to the window chrome (OS-rendered), they appear to be similar. It just looks like this is a screenshot of a low DPI display. Nonetheless, peeking at the repo's issues shows that high DPI displays haven't quite been figured out either:

https://github.com/rxi/lite/issues/46

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

#73
post #35

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…

[deleted]

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

#74
Typing latency as measured by typometer is quite high on kwin (no compositing). Both kate and Howl do much better. And pycharm. Great start, but it's not defeating vscode in the one aspect I care about: typing latency.

Kate is a surprisingly good/fast editor nowadays.

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

#75
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…

FWIW this is basically "dirty rectangles" which was a very common technique for avoiding full screen updates in games back when the hardware wasn't fast enough to do that.

[deleted]

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

#76
post #35

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…

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

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

#77
post #71

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.

[deleted]

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

#78
post #71

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.

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?

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

#79

Looks nice. But upon starting it up I lost all windows decorations (KDE), had to restart my session and lost the things I was working on in my terminals. How can launching an app cripples the whole desktop ? (not that this have anything to do with the app to me, it's a plasma thing) First thing I look for was support for vim keybinding, could neovim be used as the backend editor ?

Also on KDE and it works fine — but I have composing turned off.

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

#80

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 of Lua), uses ClearType.

Post reply on HN