Original lite is a clean and elegant Lua implementation of text editor with quite a few features. Lite-xl does the last mile to better integrate with OS and does many features that were out of scope of lite, for example multiple cursors. In that sense lite-xl is like you say a bit more complicated, to make it actually useful for everyday tasks.
I use lite embedded in my own application, and lite-xl as a quick and competent note-taking application (with custom plugin to set filename to date + document header). Both are great to me in their own ways.
Yeah, lol. It's a balancing act. Ideally we give it just enough juice to allow for things like native plugins, and the easy expected core stuff like nice font rendering
, process management, multicursors, etc.. and then leave the rest to a really robust plugin ecosystem that wasn't possible to the same degree under lite.
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
> 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 is Vim, Neovim and Emacs which all have shown that they will stick around for a while, so I really don't get what you mean.
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 prefer that, it may not be as convenient as a GUI-based IDE for some of us.
Emacs is not "command line stuff", it has a fully featured GTK based GUI interface, it even runs natively on Wayland today!
I just wanted to point this out because it's extremely common for people to assume that Emacs is a terminal based program since it's often grouped together with and compared to (Neo)Vi(m).
It's not really logical to compare Emacs with the Vi style editors since they are completely different things. It's kind of annoying that it gets grouped in with them, since it probably causes a lot of people to never even give it a fair chance.
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.
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.
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.
> 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
Why?
Neovim has multiple package managers. It has GUIs like https://github.com/neovide/neovide, it has support for LSP which can do something? Many people are comfortable with programming in an environment like that
It also has a terminal (even though if you use neovim you probably prefer to open terminals outside the IDE) and support remote editing too
Yeah its basically a Do it Yourself kit, not sure if you got the message I wrote in my comment. That is a negative, not a positive. Majority of the people don't have the time, or in many cases competence to spend several man months/years building things like these. Even if you do, you still won't be close to the complete vscode experience.
There's not much difference between installing LSPs in VSCode and adding plugins to Vim using Pathogen, vim-plug, or the built-in plugin manager. It's not as if I wrote Pylint myself, I added "dense-analysis/ale" to my config and I was done.
I think you're coming from a place of strong familiarity with IDEs, but less familiarity with Vim. From my point of view, if you asked me to switch to VSCode, I probably wouldn't ever be as productive as I am now. This isn't because I was forced to spend hundreds of hours configuring--I was one of those people with a 5 line .vimrc for years--rather, it's because I have the ability to conform Vim to my way of thinking and working.
Some people do go ham with their configs, and it's super cool that that's possible (something you can't really do with IDEs). But I think most people probably install a few plugins/language servers, set a few variables for modelines or whatever, and they're good.
>>There's not much difference between installing LSPs in VSCode and adding plugins to Vim using Pathogen, vim-plug, or the built-in plugin manager. It's not as if I wrote Pylint myself, I added "dense-analysis/ale" to my config and I was done.
You just explained the difference in this very statement yourself. Installing a plugin in vscode is a one step process. Installing it in vim is going on shopping spree for a car first, then using the car to go on shopping spree using that car. Along the way being knowledgeable enough to occasionally service the car.
>>I think you're coming from a place of strong familiarity with IDEs, but less familiarity with Vim.
Nearly my whole career is basically writing ginormous quantities of Perl/Python/C over terminals, and I happen to be one of the heaviest users of vi(m)/emacs, on Solaris/AIX machines, then FreeBSD and now Linux. I still believe macros are the most magical things you can every touch in any piece of tech.
These days I do nearly every other kind of development, and on several different platforms. And honestly speaking, merely hours of using vscode was enough to convince to use better tools to do my job, nothing wrong with that. Its just vscode does a lot more than being a code palette.
>>This isn't because I was forced to spend hundreds of hours configuring--I was one of those people with a 5 line .vimrc for years--rather, it's because I have the ability to conform Vim to my way of thinking and working.
As a old vi(m) user, my biggest productivity steals come from learning the native design choices, and learning to use them well.
This is the same philosophy I carry over to vscode as well. The thing here is magically enough vscode does a lot of things really well out of the box.
- Added "Plug 'weirongxu/plantuml-previewer.vim'" and "Plug 'akit/plantuml-syntax'" to my init.vim
- Ran ":source ~/.config/nvim/init.vim"
- Ran ":PlugInstall"
At least to me, this is the same as opening up the plugin catalog in VSCode and picking stuff.
---
I do a lot of varied development across different tech too: React, C, Svelte, Python/FastAPI/Django, Go, Lua, various SQLs, protobufs, JSON, CSVs... just all kinds of stuff. I've found Vim to not only be adequate, but excel. Maybe VSCode is great at all of these things, but that's not my point. My point is Vim works for me in the case you're describing, lots of different kinds of development on several different platforms.
> The thing here is magically enough vscode does a lot of things really well out of the box.
I think this is maybe the crux of our disagreement: you're pretty anti-config. I'm not wild about config either, some people's .vimrc files make me shudder, and when I learned about EMACS config bankruptcy I laughed out loud haha. But like, I like that I can set my default tabstop and shiftwidth, or change it per-language. I like that I can set hlsearch and incsearch. And I like that I can drop my config on almost any machine running and I'm in my element. There's a balance to strike, for sure, and maybe it is nice to sort of live out of a suitcase for your work life as it were. But for me, I've enjoyed decorating my work home.
It’s basically the best of both worlds—-IDE--like functionality all set and ready to go out of the box but totally customizable. And blazingly fast; launch times are < 1 second in most cases.
Tried to install LunarVim a few months back and it stubbornly refused to install because I had to manually install some dependencies, and then it had issues with the versions of those dependencies. It didn't even have a brew package.
Life is too short to waste working around these issues, when there is already vscode, why should one go about wasting hours to weeks of time working around these tools which don't even give a full experience.
In some cases, like this this tool in current discussion 'Lite' aren't even actively maintained(a.k.a abandonware).
I like Zed currently. It seems to get closest to my IDE needs by natively integrating with LSP while still being ridiculously fast (that <1 startup time).
JetBrains is building Fleet, which is also nice, but by comparison to their existing suite extremely lacking.
Zed talks about those two IDE's I mentioned in their FAQ, so I really would like to try it. But you can't as a normal user for now. But I'm looking forward to try it some day.
> 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.
I think I get what you mean here: over time there have been many editors that might have contributed ideas to others, yet didn't quite make it themselves, due to either competition, failing to capture a significant market share, or any number of other factors.
In my eyes, this is especially prevalent in regards to browser based (e.g. Electron) editors.
Atom, which you mentioned, fits into this category: https://atom.io/
There was also Brackets, which similarly fell by the wayside: https://brackets.io/
Here, Visual Studio Code largely got a large market share and quickly displaced other options in the eyes of most developers: https://code.visualstudio.com/
Even in regards to native editors, there are many smaller projects.
Here, however, there are more platform-specific options, and many older projects that are still going strong: Sublime Text, Notepad++, Vim, Emacs and so on. Not all of those are open source, though.
That said, while using a lesser known editor always comes with the risk that it'll be deprecated and won't see language integrations/features/plugins that you need, an editor's popularity isn't the only measure of success.
Some people don't mind using niche projects, because they feel comfy or fit their workflows well and that's good enough.
> The only real open source project that is up today is Visual Studio Code, but that will continue to be maintained, I hope.
I wouldn't say that the larger projects are the only "real" ones, though. Admittedly, it is also reasonable to generally go for the larger projects, if you want a more stable long term experience, though.
lite-xl just did a new release - it's still being actively developed, although only by a few people; but one of the focuses is the small & maintainable codebase.
There were some minor issues having the dev team get a working macbook that could test some stuff, to make sure there were no regressions. We're going through and closing PRs now, so hopefully should transition to a full release shortly.
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.
Lite (and lite-xl) is an amazing little editor. I especially love how fast the program opens. There’s just a few small things that bother me enough to keep me from using it, but I remain impressed by the code and how lightweight it is.
Hey; I'm part of the dev community over at lite-xl; what're your top asks? I can see if we can throw it into the feature queue (though the queue is already pretty long).
Thanks for reaching out! At the moment I can't think of anything specific. It was just some small papercuts that added up enough to prevent me from using it regularly, not a lack of features. But lite-xl did show me that building a text editor isn't as difficult as I first thought, and I now have many ideas for my own personal editor that I might make one day. If I ever give lite-xl another try I'll be sure to share any requests
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.
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.
If remember correctly, the [Howl editor](https://howl.io/about.html) has Lpeg and use of scintillua. It looks great and it's older but I'm not sure why Lite got more press coverage.
Yes; people have built these before, so it's not really a problem with the source (I've even cross-compiled it for arm android); it's more just not part of the pipeline yet.
Given the prevalence of mac, this makes sense to support; but apple makes it really tricky to do things if you don't actually have mac hardware; even getting the x86_64 mac build built properly is a real struggle. So, we'll certainly try.
Faster than Sublime Text? Faster than gVim? Faster than Notepad.exe?
I don't like the word "fast" when it comes to describing the startup time of a text editor. Cold boot startup is a reasonable metric to benchmark reliably.
Some text editor out there is being marketed as "blazingly fast" because of the sole merit of the language they used to write it. But on a personal level, I found it to be as fast if not a bit slower than VS Code.
Here it opens faster than Sublime Text and much much faster than VSCode. Between Notepad and lite-xl I'd say the startup time difference isn't perceivable, and lite is far far more powerful.
It might not make a difference when using it as IDE - you fire it up in the morning and keep it opened. I use lite-xl as a second editor for occasional note entry and it starts up instantaneously. I found that using a second dedicated editor just for notes is excellent for window management and for cognitive context switching; I hated having notes buried somewhere in main editor tabs among open source code files.
Thank you for the recommendation. Just installed it is indeed fast. Will use it for a couple of weeks to see how things goes.
I have a separate 2009 ear 2 gb ram laptop which I am using as my note/comm device. I am using "mouse without borders" to control that device. I have a github repo as my note repo with VS code online. But I am looking for a better solution. I need to sync notes on both devices with vim bindings.
If you're at all interested (though I'm not doing releases yet), I have a fork called 'write-xl' (https://github.com/adamharrison/write-xl), which does have a git plugin that autocommits+pushes to git on double save (double ctrl+s), as well as a bunch of other standard markdown creative writing stuff (bolding on ctrl+b, spellcheck, etc..) . I use it on my android tablet for creative writing, and have disabled a bunch of the more expensive computations to get a smoother experience.
Are you interested in releases for something like that?
This is neat. I remember learning some Lua in order to write some custom Redis functions, and I was blown away by how handy of a language it can be. The indexing definitely tricked me a few times though.
Yeah; the indexing is weird when you're not used to it; but honestly I find starting arrays at 1 is actually incredibly useful for business logic. It's terrible for math, but it allows you to use things like truthiness really effectively for compound statements that return indices and stuff.
Like, for example, `string.find` returns the index where something's found. You can just do `if str:find("a")` if you want to test to see whether a string contains "a", whereas in most other languages that test for location you're required to check that the result isn't equal to `string::npos`, `null` (if your langauge supports that), `-1`, or some other value that's not 0. Lua, you can assume that it's truthy if it's found, because 1 is the start of the string, not 0.
Took me a while to get used to, but I really like the idiom now for things that just high-level string stuff, and glue code.
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 the equation. So you can do things like that, regardless of the truthiness of 0, because it's not used, whereas in other langauges, you usually have to check, unless they have 0 as truthy as well. (though I guess this isn't much of an argument in favour of 1-indexes)
>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.
>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.
I've looked at this codebase and that of the XL version. Can a neone explain why there's C code there if it's meant to be lua? Genuine novice question. Thanks.
The other replies are correct, but there is a bit more to it.
Lua is a very small language with a tiny standard library. To extend it you write modules in C (or another language with bindings). This allows connecting the Lua code to various libraries. A notable example in lite is SDL. Without the C code in this repo the Lua code wouldn’t be able to use SDL for drawing or inputs
The C is mainly used to wrap the Lua interpreter, so that the editor can be distributed without the need for the user to have a compatible Lua interpreter installed.
No idea about this project in particular, but Lua is designed with C operability in mind. It's very easy to integrate the two languages together and this is often done so that you can have performance-constrained code written in C with higher level scripting done in Lua.
Looks interesting. Especially in terms of its customisability, this reminds me a bit of Textadept, another Lua-based editor: https://orbitalquark.github.io/textadept/
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.
I am using this editor for months now. Really happy, his strength is customization, the source code is so simple (c and lua). I have adapted it to my work perfectly, easier than (neo)vim or emacs.
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.
