Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lite XL: A lightweight text editor written in C and Lua

lite-xl.com

Post reply on HN
Print view View original

131–140 of 151 posts

Re: Lite XL: A lightweight text editor written in C and Lua

#131

Post by giancarlostoro »

maegul wrote: post #110
p-e-w wrote: post #103

Lite XL is a small miracle. I can only echo other comments calling it an "open source Sublime Text". It is at least as responsive as Sublime in my tests, and feels even more lightweight. The executable is only 385 kilobytes on Linux, with just a handful of extremely basic system dependencies (SDL, Lua, FreeType, PCRE). Sublime Text is now getting squeezed from "above" (by VSCode) and from "below" (by Lite XL), while…

Sublime has, I think, a relatively loyal user base that have gotten comfortable there and don’t really have much of a reason to leave unless for a big IDE for specific projects. The plug-in ecosystem, while clearly aged, still has activity and new developments including adapting the new LSP stuff pretty well, and has some damn committed authors/maintainers. I’ve been a comfortable user for a while now and enjoy knowi…

What Sublime is missing for me is more of what VS Code kind of has, a little bit more UI for some of its existing features, like installing plugins or if you get the ColorSublime plugin it would be nice if that had its own tab.

Sublime is coded in C++ unlike VS Code which is TypeScript and can be iterated through in an afternoon and expanded. So iterating the UI is insanely easier, even building custom things.

I think Electron proved we need an open spec for UIs and it needs to be designed to be a fully native UI that anyone from any language can pick up the library and have a powerful near native UI stack and if you switch languages you can keep your UI specification, I think of things like GLADE with Gnome (or was it GTK?) and such, but much more lightweight and specific to just UI.

Re: Lite XL: A lightweight text editor written in C and Lua

#132

Post by xmcqdpt2 »

p-e-w wrote: post #103

Lite XL is a small miracle. I can only echo other comments calling it an "open source Sublime Text". It is at least as responsive as Sublime in my tests, and feels even more lightweight. The executable is only 385 kilobytes on Linux, with just a handful of extremely basic system dependencies (SDL, Lua, FreeType, PCRE). Sublime Text is now getting squeezed from "above" (by VSCode) and from "below" (by Lite XL), while…

People grow very attached to their editors. I had a professor in university who paid 100$ every year for his subscription to

https://crisp.com/

which he used for email and notes. He has a windows workstation set up with KVM (because the department is Linux based) solely so that he can use Crisp.

Sublime could easily survive another 30 years in some reduced capacity.

Re: Lite XL: A lightweight text editor written in C and Lua

#134

Post by rd07 »

aethy wrote: post #58
iza wrote: post #13

I use this on an ancient Chromebook because VSCode and Lapce feel sluggish in comparison. What it really needs is a plugin manager.

We actually do have one, about to be released: https://github.com/adamharrison/lite-xl-plugin-manager Comes with a plugin to provide a gui in lite-xl. Once this gets to 1.0, we'll probably start bundling it with the `addons` release.

I hope LPM gets to 1.0 soon. Having to download a lua file or clone a repository to plugins directory is easy, but it can get messy overtime. Also, I hope Lite XL has a plugin store/market like Sublime's packagecontrol.io or open-vsx.org. I think the current lite-xl-plugins repository is just too basic.

Re: Lite XL: A lightweight text editor written in C and Lua

#135

Post by JonChesterfield »

sph wrote: post #129
JonChesterfield wrote: post #128

Earlier quoted context omitted.

I'm not so sure about lua != lisp. You have lexical scoping and first class closures. Tail call optimisation and garbage collection. The compiler is present at runtime. A small core which is extensible in itself or native language, e.g. to swap out doubles for bignums. I think there's s expression syntax for it as a third party project. You don't have macros as far as I can tell, though meta lua looks suspiciously cl…

Meta programming. Code is data is code. First class macros. Lisp is an abstraction level or two above what can be done in Lua. Of course Lua is a Turing-complete language, but so is Brainfuck. The main thing is Lisp doesn't have a structure, so it can be and represent anything, a little like written text. I do not want to sound condescending, I just hope to convince you to try something new: have you used a Lisp lang…

Thanks for your reply! Wise to check assumptions.

Yes, written a compiler in common lisp and various toys in scheme. Spent some of yesterday porting functions from SRFI-1 to Shutt's Kernel which is pretty close to a lisp. Interesting that you claimed first class macros, they're usually second class in lisps.

I like scheme because I'm far enough down the compilers rabbit hole that language syntax looks like obfuscation in the way of the SSA representation. Writing the syntax tree directly is attractive there.

I find macros pretty confusing. Common lisp has straightforward behaviour but needs a lot of ceremony to make them reliable. Scheme's hygienic rewrites look simple but I don't understand the machinery behind them. Lexically scoped fexpr have obvious behaviour and implementation hence the interest in Kernel.

Which is to say I'm not disputing the lisp ~= lua premise from a position of total ignorance. The semantics look pretty similar to me. Lua doesn't have control over syntax, in (reader) macro sense, so perhaps it's metalua I should be equating to scheme. As above I'm not very focused on syntax.

I also write a lot of lua so am keenly interested in the distinctions I'm missing in the above.

Re: Lite XL: A lightweight text editor written in C and Lua

#136

Post by JonChesterfield »

WalterBright wrote: post #12

Here's another one with a very small footprint: https://github.com/DigitalMars/med It's the one I use every day. The executable on Windows is a little over a meg. It also works on Linux and Mac.

'med' stands for 'Micro Emacs in D'. You're living the toolmakers' dream Walter, thanks for the link.

Re: Lite XL: A lightweight text editor written in C and Lua

#139

Post by lexoj »

aethy wrote: post #47
lexoj wrote: post #21

I like it, very fast, but it has some issue with idle CPU usage on my M1. It stays at 70% on idle whereas sublime at 0.0% when not used, opening the same project.

Yeah; unfortunately, none of the core dev teams work on Macs, so while being known, it's hard to fix on our end. We'll get it eventually.

Thank you for fixing it so quickly!

Re: Lite XL: A lightweight text editor written in C and Lua

#140

Post by the_onion_hater »

maegul wrote: post #110
p-e-w wrote: post #103

Lite XL is a small miracle. I can only echo other comments calling it an "open source Sublime Text". It is at least as responsive as Sublime in my tests, and feels even more lightweight. The executable is only 385 kilobytes on Linux, with just a handful of extremely basic system dependencies (SDL, Lua, FreeType, PCRE). Sublime Text is now getting squeezed from "above" (by VSCode) and from "below" (by Lite XL), while…

Sublime has, I think, a relatively loyal user base that have gotten comfortable there and don’t really have much of a reason to leave unless for a big IDE for specific projects. The plug-in ecosystem, while clearly aged, still has activity and new developments including adapting the new LSP stuff pretty well, and has some damn committed authors/maintainers. I’ve been a comfortable user for a while now and enjoy knowi…

The main pain point of Sublime has always been it's extensibility, or lack thereof. The program is very rigid, and the plugins can't do much.

Mainly when creating user interfaces, you can't have buttons (for example a "run" button), the only official UI components are the command palette where you search commands, and a "panel", which is basically a single separate text view.

Plugins such as the terminal plugin [1] uses this panel to show an interactive terminal, but anything you do, such as call another plugin, or simply search text, will remove your panel and replace it with another.

The only ways to create real UIs are with very ingenious workarounds, notable mentions being:

- The color picker plugin [2], which literally bundles a small native executable for each platform it runs, containing a color wheel, which the plugin will call, the user will select a color, and the program will close, returning the color code in its exit code, which the plugin is listening to.

- The debugger plugin [3] which has the most complex workaround I have seen using sublime's html capabilities. It uses the panel to show html elements, buttons with images, texts, lists, tabs, everything thorough this workaround. But again, try to search text and you loose it.

That's mainly where VSCode "won", although I still daily drive Sublime when I am not on a "full blown IDE".

[1]: https://github.com/randy3k/Terminus

[2]: https://github.com/weslly/ColorPicker

[3]: https://github.com/daveleroy/sublime_debugger

Post reply on HN