Show HN: Lite – A small, fast text editor • Hacker News Board

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

#111

Post by eyelidlessness » Sat, May 09, 2020, 8:20 PM UTC

c-smile wrote: post #101

eyelidlessness wrote: post #76

Earlier quoted context omitted.

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

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 that, and React's (in particular) has been adapted to many other rendering targets.

I'd be happy to learn more if you'd be kind enough to explain what I misunderstood.

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

#112

Post by nonesuchluck » Sat, May 09, 2020, 8:21 PM UTC

fareesh wrote: post #106

I would really like something as simple as windows notepad which syncs to my devices, where the app is equally simple. A no frills fulltext search feature would be nice too. I currently use Google Keep, which is incredibly slow

I love the mobile and web versions of Simplenote from Automattic--decent searching, basic markdown, perfect sync. But I do wish the Windows/Linux clients weren't Electron. There's a good native Mac client at least.

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

#113

Post by greendude29 » Sat, May 09, 2020, 8:21 PM UTC

Very cool.

Any plans of getting this into the arch repo?

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

#114

Post by giancarlostoro » Sat, May 09, 2020, 8:21 PM UTC

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.

Electron is like a whole framework say JVM or .NET but for JavaScript GUIs... Its definitely heavier than a few thousand lines of C and Lua vs the amount of code behind both Chrome and Node.

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

#115

Post by sp332 » Sat, May 09, 2020, 8:23 PM UTC

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.

What would the defining difference be between the two? "Forward" along what dimension?

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

#116

Post by snazz » Sat, May 09, 2020, 8:25 PM UTC

fergie wrote: post #97

Whats the advantage of Lite over Vi or Emacs?

I like Vim (and I've tried Emacs), but there's certainly still room for a small, hackable text editor that can be used with the same intuition that applies to the rest of a modern computer. Vim and Emacs keybindings require a time investment (that some people find worth it) to learn and get comfortable with.

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

#117

Post by pvg » Sat, May 09, 2020, 8:28 PM UTC

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…

I don't think Apple uses ClearType and OS X defaults to no AA on retina displays.

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

#118

Post by sp332 » Sat, May 09, 2020, 8:30 PM UTC

userbinator wrote: post #108

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…

Notepad is basically a wrapper around a text box provided by the Windows native UI libraries. The binary is so small because the heavy lifting (such as there is any to be done in Notepad) is handled by the platform.

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

#119

Post by moonchild » Sat, May 09, 2020, 8:31 PM UTC

p4bl0 wrote: post #44

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…

You might also be interested in kilo: https://github.com/antirez/kilo

Or, for something really minimal, two kilo - https://github.com/moon-chilled/Two_Kilo/blob/master/two_kil...

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

#120

Post by moonchild » Sat, May 09, 2020, 8:33 PM UTC

ccmcarey wrote: post #87

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

It seems to include the entirety of Lua - https://github.com/rxi/lite/tree/master/src/lib/lua52 Which is written in C.

Odd that they chose lua 5.2. The most popular luas nowadays are 5.1 (the version that luajit implements), and 5.3 (which was for a long time the 'latest and greatest', though it's been superseded by 5.4).