Live data from Hacker News

Lite: A lightweight text editor written in Lua

github.com

41–50 of 81 posts

Re: Lite: A lightweight text editor written in Lua

#41
post #27

Earlier quoted context omitted.

I don't mean to screw up the whole vibe of your comment, but... if 0 then print('0 is true') else print('0 is false') end prints "0 is true". The reason why "you can just do `if str:find('a')`" is because it returns nil. string.find never returns 0.

That's what I mean. It never returns 0, so is thus always truthy if it finds something. If you do `if (str.indexOf("a"))` in javascript; you'll miss out on the case where the string starts with "a", because the index returned 0, which is falsy. EDIT: Oh, sorry, I see what you mean. You're right, my bad. EDIT2: I guess, let me rephrase. 0 is rarely returned for things, so the falsiness of it doesn't usually enter into…

Some additional context for us lua noobs:

>Conditionals (such as the ones in control structures) consider false and nil as false and anything else as true. Beware that, unlike some other scripting languages, Lua considers both zero and the empty string as true in conditional tests.

https://www.lua.org/pil/2.2.html

>The basic use of string.find is to search for a pattern inside a given string, called the subject string. The function returns the position where it found the pattern or nil if it could not find it.

https://www.lua.org/pil/20.1.html

Re: Lite: A lightweight text editor written in Lua

#42
post #22
post #5

So it uses SDL2 as a rendering engine. Does it roll its own widget library?

No; rxi wrote a rendering cache infront of the renderer. It doesn't require a widget library for this reason; it's able to efficiently implement an immediate renderer. Simplifies the codebase a lot.

If you are interested, the write up on the cached software renderer used in Lite is written up here: https://rxi.github.io/cached_software_rendering.html

Re: Lite: A lightweight text editor written in Lua

#43
post #20

Earlier quoted context omitted.

Modern Emacs, at least, works better in GUI mode than in terminal mode. It's got a different style and design philosophy than VSCode et al—which results in a steeper learning curve for most people—but it's absolutely comparable in capabilities and general experience. Pretty sure the same is true for Vim or Neovim, but can't vouch for them because I do not use them myself.

Pretty sure the same is true for Vim or Neovim Yes; especially Neovim, which not only has several GUI’s but it's designed to be embeddable, including into VS Code or a web browser. Neovim has native support for LSP and Treesitter, which enables it to IDE-like things. Neovim is extensible using Lua 5.1 and comes with LuaJIT for speed. It’s not just a command line thing.

No, it is a command line thing. Neovim and vim are just the editor component of the bigger tools that is something like vscode.

To get Neovim kind of things to be anywhere near usable for modern day development work, you need to bolt a file browser, intellisense, command line section, remote editing section, container plugins, plugin installer, settings section etc etc on top of it, and is not really a trivial job for everybody to do this from scratch. Hence the use is by and large restricted to one off server side editing(This itself is getting rarer these days with containers).

In cases where Neovim is plugged into thing like vscode the experience is less than seamless. You have to keep moving between mouse and keyboard modes, formatting plugins like black for Python don't autoformat on save like they do on normal vscode editor. The intellisense doesn't work, etc.. Apart from bare minimal modal editing you really get nothing much.

To make vim/Neovim/emacs nearly as usable you need to reinvent these editing ideas but in the paradigm of modern day development workflow. And it needs be as ubiquitous as vscode. There must be little configuration work and things must work out of the box.

And lets be honest typing speed is not even relevant to software development speed so the editing efficiency gains in vim/emacs, while might save your day in heavy lifting text tasks via macros. They don't add that much gains to your workflow in normal development scenarios.

Re: Lite: A lightweight text editor written in Lua

#44
post #40

Earlier quoted context omitted.

So? It's a text editor. It's not like it's dependent on continued uptime of cloud services to function...

It is common for build time or runtime dependencies to change in incompatible ways meaning eventually you might not even be able to run it or even built it from source.

a dependency change is no longer an author's problem when they have pinned down versions.

Re: Lite: A lightweight text editor written in Lua

#45

Earlier quoted context omitted.

> There are many such projects, like Atom.io, whose support ends this year. I can't imagine this project will continue much further, even if I hope so. The only real open source project that is up today is Visual Studio Code, but that will continue to be maintained, I hope. What do you mean real open source project? I mean Linux is not going anywhere soon I'd say, or blender. Or are you talking about editors? There i…

I mean open source IDE's, real full featured developer environments for writing code. I don't talk about Open Source projects in general, but about competition for VS Code or Eclipse. There is something like Sublime Text, but it's not really open source and free. Edit: With Vim and stuff I get your point, but I would say it's not really comparable to an UI-based IDE, it is command line stuff. Even if many people pref…

https://lapce.dev/ is looking better every time I check

Re: Lite: A lightweight text editor written in Lua

#46

The community decided to work on a fork of it and extend it further: https://github.com/lite-xl/lite-xl

There are many such projects, like Atom.io, whose support ends this year. I can't imagine this project will continue much further, even if I hope so. The only real open source project that is up today is Visual Studio Code, but that will continue to be maintained, I hope. Edit: Oh wait, I forgot Eclipse... That heavy thing :P

what are you talkign about? vim (and variants), emacs (and variants), vscode, vs community, eclipse, codeblocks, gnome builder, kdevelop, and probably a bunch more I can't think of.

Re: Lite: A lightweight text editor written in Lua

#49
post #47

The community decided to work on a fork of it and extend it further: https://github.com/lite-xl/lite-xl

Any idea why it was forked?

rxi, lite's original author, considers lite to be complete, and isn't accepting new feature prs, which is fair enough.

lite-xl was forked to keep the same general principle of simplicity but going a bit further with features.

Re: Lite: A lightweight text editor written in Lua

#50
post #33

Earlier quoted context omitted.

Fair enough; totally understand. If you ever can think of anything please don't hesitate to fire up an issue on the tracker. We're (very slowly) going through them.

Personally, I'd like to see Lpeg integration, and support for Scintillua lexers: https://github.com/orbitalquark/scintillua Which would give fairly complete syntax coverage, and a good foundation for building more sophisticated tools. Lua patterns are fairly primitive, while the opposite is true of Lpeg.

It's unlikely that we would include that in core lite-xl due to size and complexity, but we aim to have an extremely robust plugin system (all current syntax definitions come from plugins).

It is totally possible to integrate an lpeg and scintilla plugin which could drop in replace the existing syntax support.

We already have a community member doing this, but with TreeSitter, though I'm not sure where that effort is at, at the moment.

Post reply on HN