It would traditionally mean a program running as little code as possible (dependencies included) for a given task, instead of relying on piles of pre-made libraries and frameworks, which obviously creep way more features than required.
However in this day and age, lightweight usually means it's not based on a web engine, although quite often it could still be huge and needlessly complex.
That doesn't prevent you from having a build path to create a .deb compatible with stable and making it available. In fact, that's a good way to improve your chances of getting into Debian proper.
"enhanced" is my branch that has a few experimental patches, a C rewrite of the tokenizer from lua; but I'd avoid it for now, as it can be slightly unstable.
"all-in-one" is my build that bundles all necessary files into the executable, so ships a completely portable, mostly statically built lite-xl as a single file.
The plugin system is a disaster in this project. Basically, each "plugin" is just a Lua script that can (and often does) modify absolutely anything in the editor, including core data structures and other plugins.
The original Lite was an exercise in creating a minimal editor, which I think succeeded. This project tries to take that base and expand it to add a ton of features, but doesn't re-architect it to support that expansion. So instead, you have a big bowl of Lua flavored spaghetti.
On the bright side though, it does seem like the maintainers are dedicated to keeping it working. So if you're looking for a text editor, you could do worse than Lite XL.
I'm not sure it's a bad thing that anything can be modified in Lua. One of the main reasons Emacs is so powerful is because almost anything can be customized in elisp. I haven't used Lite XL and this is just an uninformed general opinion.
Lua != Lisp. This distinction is quite important and often understated.
You can make a very customisable editor in a very flexible meta language like Lisp. If you do it in Lua, you have an absolute mess. I spent a few days studying Lite XL's source code before deciding the choice of language was going to be its downfall, unless they adopt very strict and well-documented interfaces.
I feel no one's trying to understand why Lisp was a thing and are doomed to try, and fail, to recreate Emacs in a subpar language. IMHO, neovim suffers from the same problem. Their choice of language is a very unstable foundation to build all those IDE-like features. vimscript is terrible, but was tailored for the problem at hand.
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
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 close to it.
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 language before? Just knowing the syntax doesn't count. People have talked about it much more and much better than I can do in a comment.
If you haven't, no worries. I recommend a weekend with Racket. Then we can disagree that Lua is a worse choice than Lisp, but at least we will agree that the latter is infinitely more flexible and malleable.
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.
Fair enough, you seem to be well informed so we can just agree to disagree.
And thanks for mentioning metalua, I had never heard of it! I know some lua but I'm far from being an expert, nor have I used it in anything larger than a few hundred lines.
I'm not the biggest fan of Common Lisp either, I too prefer the Scheme side of things though I don't think we haven't reached the golden standard yet (in my mind it would be a Clojure-like functional Lisp with first class support for actors, that compiles to native code)
Honestly, the thing that made me step into this project was actually this plugin interface.
Adding support for halfway decent Perl syntax highlighting took literally 5 minutes with no familiarity with the editor at all, and not having used lua in years.
It was extremely straightforward and refreshing, compared to say, writing a plugin for something like Code::Blocks.
This is the reason why I love it. Yes, it's not pretty, but you can hack anything into it really quickly. The fact that it's so 'informal' is the reason why it works so well imo.
That mutability is what Firefox XUL offered to extensions for many years, and when it was taken away there were — and still are — cries of outrage from devoted extensions users who expected to be able to modify anything.
So the model has lots of downsides, but certainly it’s not a dealbreaker.
Last time I looked it was simple software rendering on an SDL windows.
As simple as it goes.
I was impressed by how fast it was given that software rendering should be quite slow, but these days CPU are so powerful that this might not be a problem
A simple OpenGL renderer could be added with minimal efforts I think.
SDL will let you push geometry directly without needing OpenGL now with its geometry API, and I think all of its drawing functions use that by default now. I don't know if that's adequate compared to OpenGL but it isn't entirely CPU bound. Dear ImGUI's SDL renderer uses it.
It's a bit more complicated to add the OpenGL renderer, because of subpixel font rendering. You need to sample the framebuffer to do it correctly in all cases, as well as a custom shader. It's on the list of things to do, but as you say, CPUs are generally powerful enough these days; so it's not super high-priority at the moment.
In most cases you should know the background color behind the text without sampling the buffer, or at least get an approximation or revert to grayscale AA when layering text on top of unknown background, but yeah I get the idea and it is an interesting trade off.
If you want a command-line text editor, try the classic ed [1] :-D This was a kind of editor you might have to use with a teletype that prints on paper.
I use this kind of editor because it works remotely over a tty interface. It's a full screen editor. The increase in utility for a graphics mode text editor is not that great for a code editor, because code is monospaced.
I don't think they were claiming that GUI editors are better... more that they have different audiences and comparing them doesn't work well due to that.
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.
Is there a lightweight/fast editor that has native support for LSP? Is it even feasible to have a "native LSP editor" that doesn't rely on a plugin system, or is LSP so open-ended that you're always going to need some scripted support in the editor to make a particular language server work well? I'm thinking something akin to nvi or nano with LSP features added on.
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.
Uses SDL for rendering the UI. While it makes it work cross-platform it unfortunately means it won't look like a native application. Then again, I don't think there's a C library which provides cross-platform native UI, only the Lazarus toolkit for Free Pascal and WxWidgets for C++.
I wonder if people actually remember how native apps are supposed to look like on any of the major platforms…
Mac users, maybe. For all other platforms, churn and barely contained web apps are really wreaking havoc on the benefit of a uniform look and – most importantly – feel.
I'm a KDE user who really likes the classic Oxygen theme, and it's annoying when certain applications (e.g. Eclipse) just look way out of place. I managed to find a decent GTK port of the theme so even Emacs and Firefox are quite well-behaved.
No idea what a Windows app looks like, though, I recently fixed my grandfather's Windows 8 laptop and immediately gave up trying to understand how theming is meant to work.
(As another KDE user) I'll second this. Electron-based apps seems to be the worst culprits -- ignore my preference settings for max/min/close buttons, frequently do away with the title bar altogether leaving me with no window resize/move and hiding away Application/Window settings options, no regard for themeing,... it's become a significant (read: near deal-breaker) for me trying out new apps.
The massive changes in native UIs look and feel over the last couple decades really has made me double down on the CLI as the best interface. The CLI and the terminal are well established UIs with no big changes in a long time. The last big development I can think of is the use of sub-commands in addition to the normal command line call parameters.
I now focus on making my shell/terminal environment as good as possible and ignore GUI land whenever possible. Which today pretty much means 99% of the time I'm running a bunch of terminals and a couple web browsers.
Visually it's not that different, of course, but I don't see a more unified interface in the terminal these days. The Amiga might have had it, with its TRIPOS arg parsing, and of course you got your language-integrated text UIs like Oberon.
But beyond that, it's a mirror of the graphical side. I mean, it's not like the GUI invented a lot of new widgets, either. There are still buttons and menus, it's just that they look and behave differently in each app. The same goes for the CLIs, where there's no rhyme or reason for all the long/short parameters, sub-commands etc.; To use the git metaphor, we're in a bathroom where all the porcelain is coming from different manufacturers and your got your brutalist toilet bowl next to your gold plated sink. And nobody knows what to do with the three shells.
> Then again, I don't think there's a C library which provides cross-platform native UI, only the Lazarus toolkit for Free Pascal and WxWidgets for C++.
libui seemed like it was going to be this, but it looks like there haven't been commits in almost 2 years :(
(I'm mostly replying to raise visibility on libui, maybe someone will discover it/help out a bit)
"Native" means compiled code (likely C/C++/Rust/Zig) for some.
And it means using platform-specific UI widget for others.
I don't care too much about the UI widget style as long as the implementation is good and responsive. I tend to use app in fullscreen (F11) with minimal chrome and to be honest I kind of like when each app has its own UI style, especially if it can be user-configured with themes.
Apple/macOS users tend to fall in the other category, following the Apple guidance, where all apps should look like they were made by the same company.
> following the Apple guidance, where all apps should look like they were made by the same company
Mac users don't want all GUI apps to look alike; however, they should follow macOS UI/UX guidelines regarding copy/paste, drag and drop, keyboard conventions, etc. The whole point is to not have users having to relearn these basics for every new application.
Developers generally get these conventions "for free" by using the frameworks built-in to macOS. That doesn't prevent developers from creating custom, stylized interfaces if that's what's needed.
Even Apple's pro apps (Final Cut, Logic, etc.) look quite different from those that are bundled with macOS such as iMovie and Garageband.
So, is it actually small or is it just small on top of large libraries which do the heavy-lifting? I mean, ok, not Electron, but an Electron-based editor could also claim it was "small".
Native UIs are becoming an anachronism pretty fast. Free-form web and electron based apps are becoming the norm and it won't be to long before people see native UI apps as some sort of weird throwback.
IE. IMO that ship has sailed and using lower level/cross platform graphics stacks make a lot more sense these days.
I'm not saying they won't still be around. They will just use lower level graphics libraries and be more free form. The days of the 'native' GUI widgets are over.
you might be right, even though I find it very depressing. Native UIs using stock elements in simple ways tends to create competent interfaces. Web and electron apps are often confusing bespoke messes.
Native-ish interfaces are still pretty prevalent on mobile though.
Can someone suggest an editor for macOS with smart text algorithms to allow work on unlimited file size or line length? I need to view unlimited text, switch between encodings (including hex) and I want editor with proper algorithms, so it'll work instantly and without loading entire file in the memory. Should support search with fast regex engine.
Editing would be nice too. I imagine editing as a sequence of actions that editor remembers and can undo/redo (including search/replace) and saving is actually applying that sequence of actions to the original file in some smart way.
Also I want it to start instantly, so I can use it as my general text file editor.
Colours, autocompletions and other nonsense is strictly not needed. Just black text on white background.
All those editors just die when I'm trying to edit a simple file of several hundreds GBs with lines of several GBs.
I'd also love something that works in this situation. I've been contemplating writing something that does this for a while now but it would take a fair bit of work for the fringe cases where I'd actually need it, so it hasnt been written yet :(
It has been so long since I last used an editor that could handle very large files or long lines, that I'm struggling to remember one. Maybe SlickEdit? The Forte Agent newsreader?
The Scintilla editor widget is the cross-platform core of several good code editors, but I don't think it qualifies in this area.
I hope someone chimes in with an answer on any OS.
Ken is correct. IIRC, the very first version of BBEdit back in 1991(?) could handle files significantly larger than memory (on a system without memory mapping, no less).
Comes sufficiently close to be worth testing the free trial.
I don't know the file size limit, but it handles multi-GB files.
Does not fulfil the hex requirement. Recognizes and edits binary files but is not a hex editor. The previously suggested https://hexfiend.com/ looks better for that.
Unlimited line length, and can either horizontally scroll long lines or wrap them for display purposes.
> UltraEdit's file handling is designed to prevent it from using all the available memory, which would stop other applications from running. What does this mean to you? UltraEdit has no real limit on file size - and can easily open, edit, and save large text files in excess of 4 GB!
I've wanted to write a small text editor for a while - cause I feel like most editors don't fit my workflow - but I've been a bit too busy with work.
I don't really care about fancy features or extensions. Let me just create "tasks" (for compiling and such) and let me execute these tasks with a single button, then let me see the output from these tasks that eventually execute some application/compiler etc. That'll let me use it for any language and task.
I'd also preferably like to use I J K L as the cursor keys and toggle "Mode" (VIM style) with TAB.
And the whole thing should just run in your terminal, which can already render text nicely.
Actually, using Org mode and the Hyperbole package in Emacs solves all the problems listed in easy to use ways except you get much more editing dunctionality rather than just the features requested. Don’t reinvent the wheel; just learn something that runs everywhere and solves your problems. You start Emacs once and then rapidly edit files from the command-line by calling emacsclient, not restarting Emacs.
- Like you said, running tasks with a button/keybind, easily customizable (Like I wanna open a config file, add a function/script, bind to key/create UI button, done, not make a "plugin" not compile an "extension" or anything like that)
- Fuzzy finding/search - ripgrep and fzf can do that, so just bundle those I guess, or write my implementation of those.
- Must start instantly, load files instantly, every action needs to takes at most 100 ms.
- Be a "portable application", i.e it sits in a folder with everything it needs and I can copy that folder to any computer and be up and running with exactly the same configuration.
- Configs in lite are all done in lua files, and there are two files that you can edit without ever having to create a plugin that are automatically loaded by the editor: your system wide user config (a lua file), and a project file (.lite_project). Both of these can bind keys, create buttons, add functions, and whatever you like, really.
- Fuzzy finding we can do, but it's not great. We're doing some work on this, but at the moment, we'll probably disappoint you.
- We should start pretty instantaneously on a vanilla config, though for large directory trees, there's an architectural issue that does make us take a bit longer, that hopefully will be resolved in a release or two. So if you have a smaller directory tree, then lite should be pretty quick; if it's large, perhaps hold off looking at it.
- lite offers fully portable releases, and infact, I have an all-in-one build that bundles everything into a single, mostly statically linked executable; it's generally very flexible about how things are deployed.
We tend to add almost all extra functionality via plugins; so if you don't want a particular feature, you can simply remove the plugin, and be done with it.
I actually authored something for this to work with my workflow on lite-xl (I compile a mid-sized C++ codebase on the regular).
It's still not really ready for release, but it's here, in case you're at all interested: https://github.com/adamharrison/lite-xl-ide ; it's a build system and debugger integration.
The build tasks don't run in a terminal however; they move over to a build window at the bottom of the editor. The execution, however, by default, runs in whatever terminal you want to configure, so the actual program output does dump to an external terminal. Unfortunately, there is no truly integrated terminal as of yet.
Edit: just tried it, it works. But unfortunately it only wraps on character, so it won't work for me now. As a writer I was looking for something more lightweight than VS code, and Lite XL looks promising. I'll keep an eye on it.
This is configurable. I use it in my android fork that I use for creative writing, `write-xl` (in case you're interested, here: https://github.com/adamharrison/write-xl ; not really ready for public consumption). You can set the word wrapping configuration via your user plugin by doing:
If you want a bit better discoverability; you may want to try the `addons` release; it comes with a settings plugin that lays out all the settings in GUI so you don't have to go through digging through the source. Could be helpful if you just wanna poke around.
I love sublime. I daily Vscode for the remote ssh integration but I always have subl open for scratch padding, notes, opening huge files etc. It’s so fast.
In my own experience, it's just as fast if not a tiny bit faster, but what it's _really_ good at is customisability. With sublime I tried once to write a small plugin for gofmt and go vet (I don't remember what was wrong with the existent ones), and I gave up because it was more complex than I anticipated. With Lite XL I did it in 10 minutes and about 20 lines of lua code (though I did use this other plugin, it's a kind of support for linters).
Whatever I wanted to do it felt like I can just open the config and hack on it. Sublime never felt this way.
An ambitious FOSS project like a plugin-rich text editor is always commendable, but - I could not understand from the FAQ what the motivation for this editor was. I mean, which itch does it scratch? Which deficiency in existing editors does it resolve?
I think the original lite scratched the itch of just being very, very simple.
This is a bit less simple, but still decidedly more so than many other editors.
It has very few dependencies, statically builds, and is just generally pretty extensible, whilst also being not an embedded web browser.
What drew me to it was just the ease of creating new functionality. When I found it, it didn't have any perl syntax highlighting, so I looked into how to add that.
It took me literally five minutes to get basic highlighting working. I'm not joking, with no previous exposure to the editor, and having not touched lua in years. After I had finished, I just kinda sat there, and went: "Huh.".
I looked over the editor, and pretty much got the gist of it in a single day. I can't say that's ever happened before to me for something so feature-filled. I've tried to add plugins to other non-browser editors (like Code::Blocks, or Padre), and it was always a complete shitshow, and incredibly time-consuming and confusing (I still have trouble compiling Code::Blocks on my system, due to a huge esoteric error dump that popped at one point, and is proving frustratingly difficult to resolve). Lite just kinda worked out of the box with no real resistance. I really liked that about it.
Me too. However it seems that all editors moved to TDI around the turn of the century. Sam is a graphical text editor that still maintains the MDI interface, but it is too bare bones for my taste.
I suppose the only featured application which still uses MDI are smalltalk derivatives like Squeak. I'll have to play with that to make sure it can access the file system external to the vm.
It's actually a lovely editor. I've used it a few times in the past, and it's lightning quick, responsive and featherlike in terms of resource use, as if Sublime was open sourced. Lite XL doesn't have fancy features, no crazy plugins, it's just a great basic GUI editor.
which is exactly what i want in a text editor. If i need the IDE features, i'd switch over to vscode, or use intellij. For quick text editing work, like changing a config file or something, this is perfect.
I don't enjoy vscode (any more) and don't enjoy IntelliJ, so I'd hope to be able to use this for IDE things.
I'd like to see an alternative to LSP created for editors like this, now that Visual Studio Code has shown not to be open. I think it could be built upon Jupyter Kernels, which really pioneered the client server architecture of LSP.
My ideal IDE would be something I would also want to use for one-off editing of config files. I did this with TextMate back in the day.
You're conflating LSP and VSCode. LSP is a completely open spec for things like autocomplete, syntax highlighting, symbol searching and so on. Any editor can use any LSP server and jetbrains is using it for new languages in their editors and fleet
VSCode is also completely open source. The only thing not "open" about it is the keys they use to make the final distributable. Even the VSCodium docs say as much. They literally just build the final distribution but with slightly different keys to point to their open source extension distribution website instead of the Microsoft one
On a surface level, this is true. Vast majority of the code that makes VS Code is MIT licensed.
But the configuration of what marketplace is used and what extensions have access to the privileged "proposed API" makes huge difference in what Microsoft/GitHub can provide as user experience and what other developers can do.
I understand the difference in UX but I'm really not concerned with that. The code itself is all open source for the VSCode client and will probably remain that way. Extensions like Pylance are replaceable and the Python extension can already just use Jedi instead. Also I'm sorry but that article is really terrible in terms of both content and layout. In terms of content, its only real argument is the .Net fiasco and some issue with Gitpod that really doesn't matter. In terms of content, the page is utterly unreadable
I'm perfectly aware of what Microsoft could do in some distant future. But as is, for all intents and purposes, VSCode is open source
> But as is, for all intents and purposes, VSCode is open source
... Except that if you use the source to make your own build, you lose the extension ecosystem that is one of VSC's major selling points. It is at best a worked example of tivoization.
You can easily just download the extension dist files and dump it in the extensions folder. Most extensions are open source too and VScode is not doing anything special with the extension files. They're mostly just JS. You lose out on the convenience of the marketplace but the open source version exists. If a maintainer doesn't have their extension on there, usually reaching out to them will have them upload it there too or as I mentioned, just clone the repo
If you want "Open Source Sublime" check out CudaText. Loads fast too. Plugins are Python (like Sublime Text) but whole thing is coded in FreePascal using Lazarus. It's really capable.
After reading your comment, I tried to setup a CudaText + LSP Plugin + Intelephense as I mainly develop in PHP. Unfortunately, my experience of LSP on CudaText is not as good as Lite XL.
Also, looking at its repository, CudaText currently only has 1 active contributor, which is a little worrying if I want to use it as my main text editor. I hope the community around CudaText become bigger because I think the concept is good, and I really hope CudaText can be on par with Sublime Text.
150 comments
[ 4.4 ms ] story [ 248 ms ] threadDerivative of lite editor
Plugins
Lightweight:
We are currently around 3MB in size and takes about 10MB in RAM (can be lower). The whole thing is just Lua running on a rendering engine.
It would traditionally mean a program running as little code as possible (dependencies included) for a given task, instead of relying on piles of pre-made libraries and frameworks, which obviously creep way more features than required.
However in this day and age, lightweight usually means it's not based on a web engine, although quite often it could still be huge and needlessly complex.
edit - post was edited in the meantime
And I haven't tested it super hard, and it's only the 64-bit build.
"all-in-one" is my build that bundles all necessary files into the executable, so ships a completely portable, mostly statically built lite-xl as a single file.
Plug-ins are not necessarily compatible
The original Lite was an exercise in creating a minimal editor, which I think succeeded. This project tries to take that base and expand it to add a ton of features, but doesn't re-architect it to support that expansion. So instead, you have a big bowl of Lua flavored spaghetti.
On the bright side though, it does seem like the maintainers are dedicated to keeping it working. So if you're looking for a text editor, you could do worse than Lite XL.
You can make a very customisable editor in a very flexible meta language like Lisp. If you do it in Lua, you have an absolute mess. I spent a few days studying Lite XL's source code before deciding the choice of language was going to be its downfall, unless they adopt very strict and well-documented interfaces.
I feel no one's trying to understand why Lisp was a thing and are doomed to try, and fail, to recreate Emacs in a subpar language. IMHO, neovim suffers from the same problem. Their choice of language is a very unstable foundation to build all those IDE-like features. vimscript is terrible, but was tailored for the problem at hand.
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."
You don't have macros as far as I can tell, though meta lua looks suspiciously close to it.
What parts of lisp do you see missing from this?
I do not want to sound condescending, I just hope to convince you to try something new: have you used a Lisp language before? Just knowing the syntax doesn't count. People have talked about it much more and much better than I can do in a comment.
If you haven't, no worries. I recommend a weekend with Racket. Then we can disagree that Lua is a worse choice than Lisp, but at least we will agree that the latter is infinitely more flexible and malleable.
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.
And thanks for mentioning metalua, I had never heard of it! I know some lua but I'm far from being an expert, nor have I used it in anything larger than a few hundred lines.
I'm not the biggest fan of Common Lisp either, I too prefer the Scheme side of things though I don't think we haven't reached the golden standard yet (in my mind it would be a Clojure-like functional Lisp with first class support for actors, that compiles to native code)
Adding support for halfway decent Perl syntax highlighting took literally 5 minutes with no familiarity with the editor at all, and not having used lua in years.
It was extremely straightforward and refreshing, compared to say, writing a plugin for something like Code::Blocks.
So the model has lots of downsides, but certainly it’s not a dealbreaker.
As simple as it goes. I was impressed by how fast it was given that software rendering should be quite slow, but these days CPU are so powerful that this might not be a problem
A simple OpenGL renderer could be added with minimal efforts I think.
the editor is a fork of: https://github.com/rxi/lite
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.
If you want a command-line text editor, try the classic ed [1] :-D This was a kind of editor you might have to use with a teletype that prints on paper.
[1]: https://linux.die.net/man/1/ed
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.
It's a good stopgap between vim and vscode
Maybe try 2.2 when it comes out?
No idea what a Windows app looks like, though, I recently fixed my grandfather's Windows 8 laptop and immediately gave up trying to understand how theming is meant to work.
I now focus on making my shell/terminal environment as good as possible and ignore GUI land whenever possible. Which today pretty much means 99% of the time I'm running a bunch of terminals and a couple web browsers.
But beyond that, it's a mirror of the graphical side. I mean, it's not like the GUI invented a lot of new widgets, either. There are still buttons and menus, it's just that they look and behave differently in each app. The same goes for the CLIs, where there's no rhyme or reason for all the long/short parameters, sub-commands etc.; To use the git metaphor, we're in a bathroom where all the porcelain is coming from different manufacturers and your got your brutalist toilet bowl next to your gold plated sink. And nobody knows what to do with the three shells.
libui seemed like it was going to be this, but it looks like there haven't been commits in almost 2 years :(
(I'm mostly replying to raise visibility on libui, maybe someone will discover it/help out a bit)
[1] https://libui-ng.github.io/libui-ng/
I don't care too much about the UI widget style as long as the implementation is good and responsive. I tend to use app in fullscreen (F11) with minimal chrome and to be honest I kind of like when each app has its own UI style, especially if it can be user-configured with themes.
Apple/macOS users tend to fall in the other category, following the Apple guidance, where all apps should look like they were made by the same company.
Mac users don't want all GUI apps to look alike; however, they should follow macOS UI/UX guidelines regarding copy/paste, drag and drop, keyboard conventions, etc. The whole point is to not have users having to relearn these basics for every new application.
Developers generally get these conventions "for free" by using the frameworks built-in to macOS. That doesn't prevent developers from creating custom, stylized interfaces if that's what's needed.
Even Apple's pro apps (Final Cut, Logic, etc.) look quite different from those that are bundled with macOS such as iMovie and Garageband.
IE. IMO that ship has sailed and using lower level/cross platform graphics stacks make a lot more sense these days.
Native-ish interfaces are still pretty prevalent on mobile though.
Oh how they laughed when Sun tried this with Java some 25 years ago...
Editing would be nice too. I imagine editing as a sequence of actions that editor remembers and can undo/redo (including search/replace) and saving is actually applying that sequence of actions to the original file in some smart way.
Also I want it to start instantly, so I can use it as my general text file editor.
Colours, autocompletions and other nonsense is strictly not needed. Just black text on white background.
All those editors just die when I'm trying to edit a simple file of several hundreds GBs with lines of several GBs.
The Scintilla editor widget is the cross-platform core of several good code editors, but I don't think it qualifies in this area.
I hope someone chimes in with an answer on any OS.
I tried to open 20GB single line text file and it started to eat RAM. I killed it at 60GB as I only have 64GB RAM.
So at least modern version does not seem to work well with big files.
vim does not seem to work either.
Comes sufficiently close to be worth testing the free trial.
I don't know the file size limit, but it handles multi-GB files.
Does not fulfil the hex requirement. Recognizes and edits binary files but is not a hex editor. The previously suggested https://hexfiend.com/ looks better for that.
Unlimited line length, and can either horizontally scroll long lines or wrap them for display purposes.
Fast regex.
Unlimited undo/redo, including search/replace.
> UltraEdit's file handling is designed to prevent it from using all the available memory, which would stop other applications from running. What does this mean to you? UltraEdit has no real limit on file size - and can easily open, edit, and save large text files in excess of 4 GB!
https://www.ultraedit.com/support/tutorials-power-tips/ultra...
I don't really care about fancy features or extensions. Let me just create "tasks" (for compiling and such) and let me execute these tasks with a single button, then let me see the output from these tasks that eventually execute some application/compiler etc. That'll let me use it for any language and task.
I'd also preferably like to use I J K L as the cursor keys and toggle "Mode" (VIM style) with TAB.
And the whole thing should just run in your terminal, which can already render text nicely.
It's also near impossible to get I J K L working as the cursor keys in VIM without having some major interference.
You could write elisp functions for your tasks and bind them to your prefered keys, with or without Evil.
With evil-mode, there's no excuse not to try it even if you find Vim's way of controlling input superior (which it as well may be).
What I want from a text editor is:
- Like you said, running tasks with a button/keybind, easily customizable (Like I wanna open a config file, add a function/script, bind to key/create UI button, done, not make a "plugin" not compile an "extension" or anything like that)
- Fuzzy finding/search - ripgrep and fzf can do that, so just bundle those I guess, or write my implementation of those.
- Must start instantly, load files instantly, every action needs to takes at most 100 ms.
- Be a "portable application", i.e it sits in a folder with everything it needs and I can copy that folder to any computer and be up and running with exactly the same configuration.
and NOTHING else.
- Configs in lite are all done in lua files, and there are two files that you can edit without ever having to create a plugin that are automatically loaded by the editor: your system wide user config (a lua file), and a project file (.lite_project). Both of these can bind keys, create buttons, add functions, and whatever you like, really.
- Fuzzy finding we can do, but it's not great. We're doing some work on this, but at the moment, we'll probably disappoint you.
- We should start pretty instantaneously on a vanilla config, though for large directory trees, there's an architectural issue that does make us take a bit longer, that hopefully will be resolved in a release or two. So if you have a smaller directory tree, then lite should be pretty quick; if it's large, perhaps hold off looking at it.
- lite offers fully portable releases, and infact, I have an all-in-one build that bundles everything into a single, mostly statically linked executable; it's generally very flexible about how things are deployed.
We tend to add almost all extra functionality via plugins; so if you don't want a particular feature, you can simply remove the plugin, and be done with it.
It's still not really ready for release, but it's here, in case you're at all interested: https://github.com/adamharrison/lite-xl-ide ; it's a build system and debugger integration.
The build tasks don't run in a terminal however; they move over to a build window at the bottom of the editor. The execution, however, by default, runs in whatever terminal you want to configure, so the actual program output does dump to an external terminal. Unfortunately, there is no truly integrated terminal as of yet.
https://www.github.com/marssaxman/ozette.git
I've used this for both hobby projects and professional work, over the years (though I often find myself using VSCode these days).
[1]: https://vimways.org/2018/runtime-hackery/
Edit: just tried it, it works. But unfortunately it only wraps on character, so it won't work for me now. As a writer I was looking for something more lightweight than VS code, and Lite XL looks promising. I'll keep an eye on it.
config.plugins.linewrapping.mode = "word"
The full list of options is here: https://github.com/lite-xl/lite-xl/blob/master/data/plugins/...
Whatever I wanted to do it felt like I can just open the config and hack on it. Sublime never felt this way.
Also it's doesn't open a proper open file dialog.
Lapce (which also isn't yet to ready to replace vscode for me yet) seems to be more complete at this point.
This is a bit less simple, but still decidedly more so than many other editors.
It has very few dependencies, statically builds, and is just generally pretty extensible, whilst also being not an embedded web browser.
What drew me to it was just the ease of creating new functionality. When I found it, it didn't have any perl syntax highlighting, so I looked into how to add that.
It took me literally five minutes to get basic highlighting working. I'm not joking, with no previous exposure to the editor, and having not touched lua in years. After I had finished, I just kinda sat there, and went: "Huh.".
I looked over the editor, and pretty much got the gist of it in a single day. I can't say that's ever happened before to me for something so feature-filled. I've tried to add plugins to other non-browser editors (like Code::Blocks, or Padre), and it was always a complete shitshow, and incredibly time-consuming and confusing (I still have trouble compiling Code::Blocks on my system, due to a huge esoteric error dump that popped at one point, and is proving frustratingly difficult to resolve). Lite just kinda worked out of the box with no real resistance. I really liked that about it.
Found it via: https://en.wikipedia.org/wiki/Comparison_of_text_editors
Also, I just noticed that VSC++ Express 2008 has MDI as well under options.
I'd like to see an alternative to LSP created for editors like this, now that Visual Studio Code has shown not to be open. I think it could be built upon Jupyter Kernels, which really pioneered the client server architecture of LSP.
My ideal IDE would be something I would also want to use for one-off editing of config files. I did this with TextMate back in the day.
VSCode is also completely open source. The only thing not "open" about it is the keys they use to make the final distributable. Even the VSCodium docs say as much. They literally just build the final distribution but with slightly different keys to point to their open source extension distribution website instead of the Microsoft one
But the configuration of what marketplace is used and what extensions have access to the privileged "proposed API" makes huge difference in what Microsoft/GitHub can provide as user experience and what other developers can do.
See this great post for detailed explanation how Microsoft created a closed ecosystem around VS Code https://news.ycombinator.com/item?id=32657709
I'm perfectly aware of what Microsoft could do in some distant future. But as is, for all intents and purposes, VSCode is open source
... Except that if you use the source to make your own build, you lose the extension ecosystem that is one of VSC's major selling points. It is at best a worked example of tivoization.
I think there's also a hacky way to let VSCodium access the VS Code extension marketplace, but I believe it's an EULA violation.
https://cudatext.github.io/
Also, looking at its repository, CudaText currently only has 1 active contributor, which is a little worrying if I want to use it as my main text editor. I hope the community around CudaText become bigger because I think the concept is good, and I really hope CudaText can be on par with Sublime Text.