Not criticism, just thinking out loud:<p>This editor claims to be lightweight, citing that it uses 30MB of RAM. But I assume that's without any extensions loaded.<p>Back in the day, though, one joke about Emacs was that it's an acronym for Eight Megabytes All Continuously Swapping. This was meant to highlight Emacs's reputation for bloat. Right now when I run Emacs it's using a lot more than 30, let alone eight. I'm pretty sure most of that is all the modes I have installed for every language I might ever use, regardless of whether I'm actually using it right now.<p>About 15 years back Visual Studio had a reputation for bloat, but my experience was that it was actually quite lightweight and snappy, especially compared to Eclipse and IntelliJ. <i>Until</i> you install ReSharper, which transformed it into 50 tons of molasses.<p>At work, Visual Studio Code currently consumes about 1GB of RAM and takes 5+ minutes to start up. On my personal computer, a 2013 MacBook, it uses more like 50MB and starts darn near instantaneously. But they're very different beasts; on my MacBook I've got it configured to only load the plugins I need for each project. At work we've got a whole dang Devcontainer that includes configuration to load I-don't-know-how-many extensions, basically anything anyone on the team has ever wanted. The devcontainer extension makes you put the list of extensions to load into a file that needs to be checked into source control. So the only way for someone to get this tool they want is to make everyone else get it, too. All to sling a relatively modest volume of Python code.<p>And of course if I try to opt out of all of that I make my life even harder. Trying to get by without that pile of crap is just spitting in the wind. Run-time requirements aren't documented; they're shoved into an undocumented and ever-growing list of Bash commands in the Dockerfile. Coding standards aren't documented or managed with something straightforward like Git hooks; they're enforced through a plugin and its configuration.<p>I do remember when vscode was lightweight. It happened to be a time when not many plugins were available. That put a hard limit on just how much bloat you could accomplish. But, of course, as soon as it got popular people started creating plugins for darn near everything.<p>Perhaps the problem isn't the editors. Perhaps it's us.
As an extension writer...<p>Writing extensions in Lua is huge. (Same as OBS) Looks very simple and productive.<p>It's one of the main reasons I've stuck to Sublime... extending with Python is very easy and works everywhere.<p>Even if both Zed and VSCode are strong in other areas.. Rust extensions makes me cringe (a build toolchain? ugh..) VSCode's inconsistent undocumented Javascript API is a pain in the butt (paste & pray driven development).<p>Will be keeping an eye on this.
Just the fact that they did such an amazing job with their documentation is as huge win for me!<p>I really liked Lite XL but back when I looked at it it was a challenge to understand it’s API and functionality.<p>Looking forward to give this a spin!
Tangential: is there an IDE out there that supports different color schemes for each window it has open? does Pragtical? I didn't see it in the docs<p>I used to like having different projects open in different windows and easily differentiate between them with their color schemes. Kinda like setting a terminal to open with a random color profile<p>It seems like vscode and sublime want to change the scheme across all the windows.
Is anyone else getting a "“Pragtical.app” is damaged and can’t be opened. You should move it to the Trash" error when attempting to run the arm64 build on macOS? Really wanted to try it out!<p>I suppose it could just be some security crap Corp IT installed on my laptop preventing it from installing.<p>It looks like it's only taking up 7.9MB in my Applications folder so it must be corrupt or something.
Why fork Lite XL instead of contributing? Just out of curiosity, since I'm not familiar with either project and don't know what their respective philosophies are.
<a href="https://github.com/pragtical/plugins/commit/54096a6461f5c034cdfcc5b528eb706d4936217f?diff=unified&w=0">https://github.com/pragtical/plugins/commit/54096a6461f5c034...</a> makes me long for The One Grammar To Rule Them &trade;<p>I thought for a while that TextMate bundles[1] were that, especially since JetBrains[2], Linguist[3] and VSCode[4] honor them. However, in the spirit of "the good thing about standards ..." highlight.js does[5] almost the same thing that Pragtical does which makes me feel <i>even worse</i><p>I had high hopes for Tree-Sitter since it seems to have really won mindshare, but the idea of having an <i>executable</i> grammar spec[6] is ... well, no wonder it hasn't caught on outside of that specific ecosystem<p>1: <a href="https://github.com/rspec/rspec.tmbundle/blob/1.1.12/Syntaxes/RSpec.tmLanguage">https://github.com/rspec/rspec.tmbundle/blob/1.1.12/Syntaxes...</a><p>2: <a href="https://github.com/JetBrains/intellij-community/blob/idea/242.21829.40/plugins/textmate/loadVSCBundles.sh">https://github.com/JetBrains/intellij-community/blob/idea/24...</a><p>3: <a href="https://github.com/github-linguist/linguist/blob/v7.30.0/lib/linguist/languages.yml">https://github.com/github-linguist/linguist/blob/v7.30.0/lib...</a><p>4: <a href="https://github.com/microsoft/vscode-textmate">https://github.com/microsoft/vscode-textmate</a><p>5: <a href="https://github.com/highlightjs/highlight.js/blob/11.10.0/src/languages/asciidoc.js">https://github.com/highlightjs/highlight.js/blob/11.10.0/src...</a><p>6: <a href="https://github.com/tree-sitter/tree-sitter/blob/v0.22.6/test/fixtures/test_grammars/readme_grammar/grammar.js">https://github.com/tree-sitter/tree-sitter/blob/v0.22.6/test...</a>
Micro-review after having used it for half a day on Windows.<p>It seems really lightweight: the UI is spartan but snappy, loading a file is instantaneous, etc. Downloading and installing a plugin is as easy as dropping a Lua file into a directory. And even after installing several plugins, the speed doesn't seem affected.<p>On the other hand, it comes with hardly any feature out of the box, and everything must be covered by plugins. The plugins are really "atomic". For example, one is to auto-indent, another one to auto-format a block; one is to highlight the matching bracket a second one to jump to the matching bracket, and a third one to automatically insert the closing bracket, while yet another one draws rulers to visualize the block between matching brackets. Do you want to set markers and jump between then? another plugin. Build from within the editor? another plugin. And so on...<p>The plugin "store" looks good, but accessing it from inside the editor is a poor experience: sometimes it just hungs and you have to restart the editor. Additionally the fact that plugins, themes and fonts are all mixed up doesn't make it easy to find what you're looking for.<p>Final judgement: if I need to select and install 10 to 15 plugins just to make it on par with a stock Vim, I'll stay with the latter.
Anyone have any experience building GUIs in SDL?<p>I have been using Flet (basically multilingual binding for Flutter) to build GUIs the last year or so, and in general the experience has been very good.<p>However, I've recently started work on a project that has need for a large number of controls--on the order of 2000 controls visible at one time--and I'm running into Flet's limitations. All the Flet controls have animations, which creates a good default experience when there's a few of them, but when you're using 2000 of them, simply passing your mouse over an area with a bunch of controls causes a cascade of small animations and the renderer explodes. Impressively, it <i>usually</i> doesn't seem to cause any performance lag, but it seems like the way they avoid lag is just by dropping the animations half-rendered which causes the window to flash all sorts of broken half-rendered gobbledygook to the screen. My approach has been to turn off animations as much as possible, but there are enough controls visible at any one time that even just rendering the without animations is running into issues.<p>I'll probably just deal with it for my first version--the core functionality is about number crunching and the user base is used to using much worse UIs--but I'm looking at lower-level tooling that can still remain cross-platform. In this post I'm seeing that Pragtical is advertising that they're written with SDL and I'm seeing some similarities between a code editor and what I'm doing, so it seems like that might be the solution to my problem.
Downloaded both Lite XL and Pragtical and have to say that Lite XL looked ok on open, while Pragtical looked super tiny and all the UI was out of alignment.
Just FYI, the thing crashed on me in inventive ways.<p>First, the ARM version, when I tried to launch it, had MacOS say it was damaged. Only option was to move it to the trash.<p>The Universal option did work, but when I tried to open a standard .c file, it crashes. It is fast though and fairly slick looking. But needs work.
I just tried it and culdn't get past the first screen.
The "installation" failed on mac and had to find a workaround just to use the editor.
All the fonts look wrong, too small and misconfigured. Maybe the project needs more time to mature, in the meanwhile, I'll stick to vim.
Like other apps that use SDL, this (Pragtical) is blurry on Gnome with the scale-monitor-framebuffer experimental feature enabled and scaling set to some value other than 1.00.
> light weight<p>Honestly that's not an issue, I would personally not base my judgment on memory usage, unless it is a memory hog.<p>I know others do but for reasons that go beyond practical. For those that have things to get done, I suspect they think like I do.
Any IDE that isn't "AI first" is going to have a hard time from here on out. Cursor is beginning to eat the world much like VSCode did.<p>I'm sure there are some here on HN that will say "nah, I prefer the old fashioned way" but you will be decidedly in the minority very fast.