Earlier quoted context omitted.
The compiler might complain that it needs SDL. Fixed this with: sudo apt install libsdl2-dev on Ubuntu. Else it works as tingletech described also using Mint/Ubuntu.
How do I install this on Mac? apt is not available in mac. Update: I can install this using brew install sdl2 https://medium.com/@edkins.sarah/set-up-sdl2-on-your-mac-wit...
Show HN: Lite – A small, fast text editor
91–100 of 276 posts
Re: Show HN: Lite – A small, fast text editor
#92Could 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?
My Lua isn't strong, but I think this is what you're looking for: Data structure initialization: https://github.com/rxi/lite/blob/master/data/core/doc/init.l... How insertion works here, which illuminates how the table is used: https://github.com/rxi/lite/blob/143f8867a13a35f5688ad7c9771...
It's two dynamic arrays, of hashes and values, whose sizes grow as powers of two.
Re: Show HN: Lite – A small, fast text editor
#93Any instructions on how to run this on macos?
brew install lincerely/tools/lite
Or brew tap lincerely/tools; brew install liteRe: Show HN: Lite – A small, fast text editor
#94Checking 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
Re: Show HN: Lite – A small, fast text editor
#95This 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
#96Thought 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 superior. Lite is pretty spartan - it doesn't even appear to have a file/directory selection dialog to open files/folders with. I really like the default colour scheme/theme Lite ships with though.
Re: Show HN: Lite – A small, fast text editor
#97Re: Show HN: Lite – A small, fast text editor
#98This 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 think this is less true when you don't assume people know all about web tech already, IOW there would be less of a difference for someone coming into software dev completely naive of web tech.
> There needs to be focus on building tooling that enables rapid development of native applications.
Fully agree.
Re: Show HN: Lite – A small, fast text editor
#99So 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…
Windows, MacOS and GTK maintain internal pixmap buffer for a window.
And when needed you call InvlidateRect(wnd,rc) and receive WM_PAINT with cumulative rect to update.
Personally, I would create an abstraction that wraps couple of functions of GDI, CoreGraphics and Cairo and use it instead manual pixmap rendering. Will be faster and more flexible. All that UI can be rendered by just 2..3 functions FillRect, DrawText, MeasureText.
Re: Show HN: Lite – A small, fast text editor
#100Looks 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 ?
KDE disables compositing when SDL apps are opened to improve performance. It should return once the app is closed. You can disable this behavior in System Settings > Display and Monitor > Compositor and unchecking Allow applications to block compositing.
It's not the first time something like that happened to me but I would never have had the patience to investigate !
Can confirm unchecking that setting solved that problem.