Beautiful. Would love to see this front a headless nvim.
Show HN: Lite – A small, fast text editor
81–90 of 276 posts
Re: Show HN: Lite – A small, fast text editor
#82Earlier 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?
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.
Re: Show HN: Lite – A small, fast text editor
#83This 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.
I'm not sure I agree. There needs to be a focus on building "quality everything" and not "quickest to make anything".
Move fast and break things has become the cancer of software engineering.
Re: Show HN: Lite – A small, fast text editor
#84Looking 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…
Yet, there is no support (yet?) for RTL languages.
Re: Show HN: Lite – A small, fast text editor
#85This 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 completely dislike the "isn't made is js/web/electron tech" argument
Because as you said "It's certainly not perfect yet"
Re: Show HN: Lite – A small, fast text editor
#86Checking 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?
Re: Show HN: Lite – A small, fast text editor
#87Checking 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
It seems to include the entirety of Lua - https://github.com/rxi/lite/tree/master/src/lib/lua52
Which is written in C.
Re: Show HN: Lite – A small, fast text editor
#88Checking 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
They have all of the lua implementation checked in, which they didn't write.
Most of the implementation is oddly in the "data" folder.
Re: Show HN: Lite – A small, fast text editor
#89Checking 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
If you check the C sources you'll find that it's Lua itself and libSDL.
Re: Show HN: Lite – A small, fast text editor
#90Earlier 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.
Nah, it's tile-based concurrent precompositing, like web browsers do. Each tile knows what's in it (i.e. what set of DOM elements); and subscribes to state-change events for those DOM elements; and any such state-change event will trigger the tile to re-render its cached texture. Then, on each frame, all you have to do to draw everything, is to grab the latest cached texture from each tile, and blit those (or set them up as a grid of flat-projected rects in screen-space, if you're in 3D-semantics land.)
You can get additional benefits from this approach, by doing multiple layers of it (e.g. having scrollable surfaces have their own tiles that precompute the inner-document-viewport-space rather than the outer-viewport-space, such that the inner tiles aren't invalidated by scrolling the outer viewport.) This technique ends up forming a tree of tiles, where tiles higher up the tree, when invalidated, re-render trivially by compositing tiles further down the tree into themselves. Thus, another name for this approach is a "precompositing tree."
The difference between this approach and dirty rects, is in the direction of information flow. In tile-based precompositing, the information only flows in one direction—from the user, through view-controller, into the DOM, to the tiles, and then out the display. Dirty rects, meanwhile, are a signal sent backwards, from the display system to the program, essentially telling it that the display system lost/discarded the information needed to re-draw an area, so could the program please send it over again. (The program doesn't even have to re-render in response; some dirty-rects implementations, like X11's DAMAGE extension, just involve the client application re-transmitting pixbuf data to the server from its own precomposited buffer.)
Also, dirty rects / screen-damage doesn't solve the problem of hardware not being fast enough; it solves the problem of hardware not having enough VRAM to do per-frame compositing from undamaged intermediates. In low-VRAM conditions, you can only keep around the final pre-composited image; and so any time you "damage" / make "dirty" a region of the screen (e.g. by removing an overdrawn element, which should have the semantics of revealing whatever was there before that element overdrew it) then you need to propagate a request back to the renderer to re-draw (and, for efficiency, re-draw just that region), because you don't just have an intermediate texture laying around for that window/stage-layer/etc. to re-source it from. If you did, then dirty-rects would never come into play, since you'd just re-composite everything each frame. (Which is cheap even on old-school CPU-only blitters—you just have to alternate which pixmap pointer you're basing your LOADs off of using either a rect-overlap check, or a mask-bitmap [which gets you 8 pixels' mask-states per LOAD.] Even the Gameboy can do it!)