[HN Gopher] Pragtical: Practical and pragmatic code editor
___________________________________________________________________
Pragtical: Practical and pragmatic code editor
Author : rd07
Score : 226 points
Date : 2024-08-20 07:15 UTC (15 hours ago)
(HTM) web link (pragtical.dev)
(TXT) w3m dump (pragtical.dev)
| vouaobrasil wrote:
| Looks a lot like LiteXL. Is it based off it? What makes it
| different?
| cation234 wrote:
| According to its Github page, yes it is a fork of LiteXL.
| throwaway744678 wrote:
| A bit of context: Motivation about Pragtical Text Editor [0]
|
| [0]
| https://github.com/pragtical/pragtical/issues/6#issuecomment...
| hans_castorp wrote:
| The user interface font is way too small and nearly impossible to
| read on a 4K monitor (on Windows)
| Fluorescence wrote:
| Looks good on my Ubuntu 32" 4k.
|
| You can change the UI font size in Settings / User Interface /
| Font (double click to edit).
|
| My main objection was "smooth scrolling" which I could turn off
| as "scroll transition". Bit annoying you can't search settings
| though. Don't know why I am looking at it though because I
| value the higher level things new editors will always be
| missing e.g. refactoring, debugging, test integration, advanced
| panel management and a million extensions I forget I rely on
| everyday.
| rd07 wrote:
| You can change the scale setting through Settings > Plugins >
| Scale and see the best setting for your monitor
| swah wrote:
| Didn't make a difference here (restarted too, ofc)
| geenat wrote:
| As an extension writer...
|
| Writing extensions in Lua is huge. (Same as OBS) Looks very
| simple and productive.
|
| It's one of the main reasons I've stuck to Sublime... extending
| with Python is very easy and works everywhere.
|
| 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).
|
| Will be keeping an eye on this.
| ta8645 wrote:
| For what it's worth, NeoVim's extension language is Lua as
| well.
| srik wrote:
| Yup. I've paradoxically found it more convenient to write my
| neovim plugins+configuration in lua than in python with
| vanilla vim's python api.
| coliveira wrote:
| Vim also has support for Lua scripts.
| throwup238 wrote:
| _> VSCode 's inconsistent undocumented Javascript API is a pain
| in the butt (paste & pray driven development)._
|
| It's so bad they have a whole Github Copilot mode specifically
| dedicated to it. Pay and pray driven development.
| lukan wrote:
| Oh and I kind of finally decided to give those shiny modern
| tools a serious try. Paste (pay) and pray does not sound too
| good on the other hand.
| p4bl0 wrote:
| That's what I really love with Kate (and actually the
| KTextEditor component of KDE Frameworks): you can build heavy
| plugins in C++ but there is also a very good JavaScript API
| that you can write new editing commands with for example.
| rd07 wrote:
| Lite XL (which is a project Pragtical forked on) is my first
| experience writing a plugin for code editor and coding in Lua,
| and I am surprised on how easy is it. I don't know about other
| editors, but in Lite XL and Pragtical I can extend or overwrite
| almost anything the core plugin is doing. I can even start
| writing the plugin in my user module file (init.lua), and see
| the change on the fly.
| kqr wrote:
| This is inspired by Emacs which works the same way. It, in
| turn, takes inspiration from how Lisp systems have worked
| since time immemorial. You're meant to open a REPL directly
| into the running system as a way to evolve it.
| hprotagonist wrote:
| and the circle is complete: https://fennel-lang.org
| pjmlp wrote:
| Yeah, I always complain about Python lack of JIT, but being
| extension language is actually a good use for it.
|
| Or Tcl, which I used 20 years ago as for our in-house proxy
| module for Apache/IIS, extensible in C and Tcl.
|
| Unfortunely out of fashion for anyone besides EDA tooling.
| theshrike79 wrote:
| Wezterm is configured with Lua, Hammerspoon configs are also
| Lua.
|
| Both are super easy to sync to multiple computers with chezmoi
| and the configs themselves can be smart enough to behave
| differently on different machines.
|
| I wish more software used Lua for config.
| daelon wrote:
| I'm a VSCode extension author and I don't really know what you
| mean by "inconsistent undocumented API". Do you have any
| examples?
| golergka wrote:
| I haven't written much vscode extensions, but I've worked
| professionally on editors that use Monaco (the text editor
| library used and developed by vscode team). There's almost no
| documentation whatsoever.
| truckerbill wrote:
| Is it possible to do custom drawing modes for diagrams and
| viewers?
| torginus wrote:
| The UI gives me a Godot-y vibe. Is there some relation?
| k__ wrote:
| _" runs locally on your machine as a CLI application"_
|
| Hrm, I was hoping it would run all in the browser.
|
| Cool idea nevertheless!
| meiraleal wrote:
| > Hrm, I was hoping it would run all in the browser.
|
| like Monaco? Or a proper fully featured text editor?
| wordpad25 wrote:
| Project was founded specifically to counter the modern trend of
| using web stack for editors
| BigParm wrote:
| How does it occupy 30MB ram but 5MB disk space does it grow
| a-french-anon wrote:
| void *p = malloc(30 * 1024 * 1024);
| genezeta wrote:
| In case your question is sincere, this is normal.
|
| Generally, a program on disk contains _code_. Part of that is
| the description of certain structures. Say you have an editor
| which can load a file, you have to have structures to hold that
| file, to keep track of the undo history, to represent the file
| with colours (syntax highlighting) and whatever. Your editor
| may have a Lua VM inside running plugins that you load. That VM
| will reserve additional memory to run those plugins. And so on.
|
| All that only exists while the program is running, but not on
| disk.
| _benj wrote:
| Just the fact that they did such an amazing job with their
| documentation is as huge win for me!
|
| I really liked Lite XL but back when I looked at it it was a
| challenge to understand it's API and functionality.
|
| Looking forward to give this a spin!
| swah wrote:
| No LLM plugins yet?
| rd07 wrote:
| AFAIK, not yet
| swah wrote:
| 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.
| Weethet wrote:
| Yeah, for me too. It looks incredibly broken as of right now
| and I don't even understand how. I'd say that it's okay if it
| was an alpha of a completely new editor, but it's a fork of a
| one that already works well, so idk, I don't expect it to go
| anywhere
| atlintots wrote:
| 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.
| genezeta wrote:
| A few comments below yours:
| https://news.ycombinator.com/item?id=41298071
| prmoustache wrote:
| Does it have a multiple modes support and vim-like keybindings
| either vanilla or through plugins?
| artemonster wrote:
| Do I understand correctly that its a software renderer? They
| manually blit a buffer from glyphs and use SDL to show it, akin
| to immediate mode?
| ben-schaaf wrote:
| Immediate mode is the way a rendering API works. Most glyph
| rendering works by blitting from a buffer, regardless of how
| they design the API.
| mosburger wrote:
| 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!
|
| I suppose it could just be some security crap Corp IT installed
| on my laptop preventing it from installing.
|
| It looks like it's only taking up 7.9MB in my Applications folder
| so it must be corrupt or something.
| kccqzy wrote:
| That sounds like a code signing error. 7.9MB is a good size.
| yas_hmaheshwari wrote:
| I have seen a similar error in the past, and that one was
| because of MacOS extended permissions
|
| ``` cd /Applications/DBeaver.app/; ls -@l ```
|
| And then if you see some extended attributes like quarantine
| and provenance, you can remove them
|
| ``` xattr -d com.apple.provenance DBWeaver.app/; xattr -d
| com.apple.quarantine DBWeaver.app/ ```
| tunaoftheland wrote:
| Haven't tried with Pragtical (hard to say it out loud BTW, lol)
| but have had success with right-click-opening other apps that
| give this error. Sometimes I need to do it multiple times to
| open it as normal. No issues with the apps themselves, has to
| do with app signing (or lack thereof for many macOS apps that
| one just downloads from a site).
| tom_ wrote:
| An error about the app being damaged specifically can stem
| from the contents of the .app folder being modified after it
| was signed with the codesign tool. You can use codesign
| --verify (consult the man page) to get some info about why
| it's being considered damaged.
|
| I've got this wrong in the past by adding the README too late
| in the process. Once I'd fixed that, the reason macOS gives
| for not opening my app became that Apple can't check it for
| malicious software. Much better... I think? The right
| click/open workaround does work.
| rpastuszak wrote:
| FWIW the universal build works with the right mouse button
| click trick
| tbeseda wrote:
| FYI, in macOS v15 Sequoia +, Gatekeeper/quarantine/signing
| has changed. Right click to open won't allow the bypass. The
| quickest way, without disabling runtime protection:
|
| `xattr -r -d com.apple.quarantine
| /Applications/Pragtical.app`
|
| -d is delete -r is recursive
|
| Hopefully, Apple won't lock it down further.
| bityard wrote:
| Hmm. That worked for me, but when I run the app, everything
| in it is reeeealy tiny. Like they're trying to work around
| Retina display scaling but got it wrong somehow.
| hoistbypetard wrote:
| I am also getting that error. I have no security crap from Corp
| IT on my personal macbook.
| brisket_bronson wrote:
| 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.
| fusslo wrote:
| 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
|
| 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
|
| It seems like vscode and sublime want to change the scheme across
| all the windows.
| avhb wrote:
| the peacock vscode extension can help you with this:
| https://marketplace.visualstudio.com/items?itemName=johnpapa...
| fusslo wrote:
| holy crap thank you
| rudnevr wrote:
| IntelliJ does, of course. Per project, per window, with
| background images etc
| r-spaghetti wrote:
| in vscodium I have a different left bar color for each project
| - not exactly what you want but I can easily differentiate
| between them. There is a workspace settings json file per
| project: "settings": { "workbench.colorCustomizations": {
| "activityBar.background": "#faf7c7", "activityBar.foreground":
| "#000000" } } (disclaimer: this works on Debian Gnome)
| TiredOfLife wrote:
| VS Code you can have different Theme per Workspace.
| mnmalst wrote:
| Doesn't pick up my (non ttf) Terminus font and there is no
| obvious way to set the font manually.
| cynicalpeace wrote:
| 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.
|
| 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.
| elashri wrote:
| I doubt that if Stackoverflow or Jetbrains surveys included a
| question about if people just heard about cursor that you will
| get more than 50%. Let alone people actually using it and
| ditching VSCode.
| cynicalpeace wrote:
| I said "beginning"
| from-nibly wrote:
| I guess I'm an old grump then. I don't want air first
| development. It should be an extension. Why would an editor
| need to have air baked in when things like language support is
| an extension?
| cynicalpeace wrote:
| It could be an extension, but its going to be so important
| that the IDE with the best AI support will be the most
| popular. Presumably that IDE won't relegate it to extension
| class citizenship. It will be most of the product.
|
| Even now, I've built a ramen profitable side project mostly
| by sipping my coffee and approving Cursor's suggestions. 10x
| faster at least.
|
| Way more productivity gains than even language support.
| Cthulhu_ wrote:
| Nah; an IDE / editor needs to be a solid, pluggable and
| performant core first and foremost, so that any addons like AI
| shenanigans are opt-in and swappable. While AI isn't new, AI-
| powered code assist is and with that in mind we're only at the
| beginning.
|
| Consider LSP, where language developers can now publish a
| single tool for language specific utilities, where before every
| editor needed to add support for languages separately. Again,
| pluggability.
| cynicalpeace wrote:
| We actually are in agreement, especially re pluggability.
|
| Whether it's an extension or "AI first", the impact of AI on
| IDE's will be massive and an IDE that doesn't do it well will
| be barely used.
| bunderbunder wrote:
| Not criticism, just thinking out loud:
|
| This editor claims to be lightweight, citing that it uses 30MB of
| RAM. But I assume that's without any extensions loaded.
|
| 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.
|
| 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. _Until_ you
| install ReSharper, which transformed it into 50 tons of molasses.
|
| 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.
|
| 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.
|
| 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.
|
| Perhaps the problem isn't the editors. Perhaps it's us.
| from-nibly wrote:
| Direnv + nix packages is way better than Dev container
| development in my experience.
| lucianbr wrote:
| It's a cycle, and we've been around the bend multiple times
| already.
|
| https://www.xkcd.com/2044/
|
| Installing multiple programs on my computer or a server is
| complicated, and slows things down, and it's insecure and hard
| to replicate. So we created VMs. And for a while VMs were
| great. But then we started putting everything we needed in the
| VMs, and they also became complicated, and slow, and insecure
| and whatnot. So we have containers. And containers are now
| slowly getting bloated too. Kubernetes simplified some things,
| but now we need Helm to deal with K8s, and Helm itself is now
| quite complicated.
|
| Editors start lightweight and fast, then get bloated with
| features. So does productivity software. Programming languages
| start simple and easy to use and understand, and progressively
| get more features, each of which seems nice in isolation, but
| soon the codebases use everything, and it interacts, and you
| need decades of experience to use it all proficiently.
|
| Same for libraries. For network protocols. For standards of all
| kinds.
|
| It's most definitely us.
| BD103 wrote:
| > On my personal computer, a 2013 MacBook, it uses more like 50
| and starts darn near instantaneously.
|
| Just for clarification, do you mean 50 GiB or 50 MiB? I'm
| assuming MiB in this scenario, since allocating 50 GiB doesn't
| mix with an instantaneous startup.
| bunderbunder wrote:
| Yeah, mib
| kerkeslager wrote:
| > Perhaps the problem isn't the editors. Perhaps it's us.
|
| For coming up on a decade I've used Vim with a minimal .vimrc
| and no plugins. The only time I deviate from this is when I am
| writing in an s-expression based language. I would probably
| deviate from this to write Java or C#, but I haven't written
| either in a while.
|
| There are upsides and downsides. The biggest upside is simply
| that I haven't spent ANY time learning new editors or new
| editor features; I'll occasionally learn about a feature of Vim
| that I didn't know existed, but that's very oriented toward
| solving immediate problems, because it tends to happen when I
| run into something that feels like there's probably an easier
| way to do it, and I'll do a quick internet search. I think a
| lot of devs spend a lot of time learning tools with the sense
| that the time spent will be paid back by time savings from
| using the tools, but the reality is way more hit-and-miss, and
| I think a lot of people could benefit from being more selective
| in what they spend their learning time on.
|
| The thing that Vim completely misses is being able to jump to
| the appropriate file where a class/function is defined. This is
| more of a tradeoff than IDE folks recognize: when I was using
| PyCharm/IntelliJ/ReSharper, I found that being able to jump
| around easily would hide the fact that my projects were growing
| in size and complexity. The tooling makes this less painful up
| front, but eventually, you still feel the pain, because
| eventually there's some bug that cascades through a bunch of
| files, and you still have to reason about all of them.
| _Finding_ definitions isn 't the core issue with having a lot
| of definitions, _reasoning about how they interact_ is the core
| issue, and the IDE tooling doesn 't solve that. Being in Vim
| and having to deal with my project's file structure directly
| and explicitly means I feel the pain of complexity earlier,
| when it's easier to fix.
|
| If I'm being honest, I'm _not_ sure that the tradeoffs comes
| out in Vim 's favor here. I don't think we get to have a
| conclusive answer because there's simply nobody who uses both
| vanilla Vim and the best IDEs at a high enough level to have an
| informed opinion about which is better. I'd say I am close
| because I have used both extensively, but my IDE knowledge is
| outdated by about a decade.
|
| But, I've said before and I'll say again that _entering text
| into files isn 't usually the limiting factor of software
| development speed_. If I'm mentoring a new programmer I'd
| rather see them learn TDD and/or how to leverage type systems
| and write code in Notepad, than see them write untested,
| unchecked code in The Best IDE/Editor Ever. Of course, there's
| no reason to go to those extremes.
| bunderbunder wrote:
| Your 3rd and last paragraphs reminded me of a feature I
| really like about F#: all source files in an assembly have an
| explicit, sequential compilation order. And you can only have
| references to things that had been defined earlier, either in
| the current file or in a file that comes earlier in the
| compilation order.
|
| It makes learning and navigating a new codebase _much_
| easier. So much so that it doesn 't really require IDE
| tooling the way it does with most mainstream languages. It's
| harder to get lost when you always know which way is up.
| Consciously thinking about whether you're doing top-down or
| bottom-up design also flows naturally from this, for the same
| reason, and that seems to encourage more thoughtful, readable
| code design.
|
| Is it more work? Up-front, yes, absolutely. In the long run,
| though? By the time I finished my first year of CS education
| I had already been exposed to many many examples of cases
| where greedy algorithms consistently produce sub-optimal
| results. Perhaps they aren't teaching people about that in
| school anymore.
| msteffen wrote:
| Wait, does F# not support mutual recursion? Can one not
| write eg a recursive descent parser?
| Iwan-Zotow wrote:
| No, this is about single pass compiler, which makes it
| fast but all references to use in current file to be
| defined earlier
| kerkeslager wrote:
| Single pass compilation can support backreferences, i.e.
| referencing a symbol and then defining it later,
| efficiently with a technique called "backpatching". All
| single-pass compilers I know of use backpatching for
| computing jumps--I'm not even aware of any other way to
| compute jumps. For symbols, the implementation of
| backpatching is a bit more complex, but it's a pretty
| well-known solution and I don't think it would be a
| significant barrier for any competent compiler developer.
| That is to say, if they've chosen to not support
| backreferences, it's not because it's hard to do in a
| single-pass compiler.
|
| EDIT: The wonderful book _Crafting Interpreters_ has an
| implementation of backpatching jumps to implement loops.
| Before anyone says "this is an interpreter, not a
| compiler", be aware that most modern interpreters contain
| a compiler. https://craftinginterpreters.com/jumping-
| back-and-forth.html
| bunderbunder wrote:
| That was why it was done that way in languages developed
| in the 1970s. But, as kerkeslager points out, that logic
| doesn't work for an enterprise programming language from
| the 2000s.
|
| We don't actually need to speculate on this. Don Syme has
| explicitly said that this was a deliberate language
| design decision meant to discourage the big ball of mud
| antipattern. And the language maintainers continue to
| cite this as the reason why they don't change this
| behavior even though they easily could.
| kerkeslager wrote:
| They do support mutual recursion, but you have to make it
| explicit.
|
| https://learn.microsoft.com/en-us/dotnet/fsharp/language-
| ref...
| mananaysiempre wrote:
| Same as the rest of the ML family then.
| bunderbunder wrote:
| Same as the rest of the functional languages, even.
| mananaysiempre wrote:
| My first functional language was Haskell, which
| essentially only has a letrec, so afterwards I've always
| viewed everybody else's approach as a bit peculiar :)
| Fair point that it's the Lisp way too.
| mjaniczek wrote:
| Nah, Elm doesn't need the rec keyword and could be argued
| to be a ML descendant
| CrimsonCape wrote:
| That sounds like a nightmare when an IDE presents files
| alphabetically but has a strict logical order that the UI
| doesn't understand. Talk about jumping around.
| bunderbunder wrote:
| Editors and IDEs with F# editing modes know how to read
| the project file and display the files in the correct
| order.
| msravi wrote:
| > The thing that Vim completely misses is being able to jump
| to the appropriate file where a class/function is defined.
|
| ctags+cscope in vim is great at this! :cs f e
| <expression>
| sweeter wrote:
| This is exactly why I switched from containers to nix flakes
| and from Vs code to neovim or Helix. The difference is night
| and day. It's so nice to have my editor open instantly and to
| be able to have multiple instances open at once. The LSP is by
| far the most memory hungry. It's definitely worth the effort.
| fredsmith219 wrote:
| Yup, it is your works crazy policy of making sure everyone gets
| a one size fit all VS code Configuration. I've loaded VS code
| on a 10 year-old Lenovo and it runs just fine with only basic
| Python plug-ins. Five minute startup time is crazy.
| kerkeslager wrote:
| Anyone have any experience building GUIs in SDL?
|
| 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.
|
| 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 _usually_ 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.
|
| 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.
| stephc_int13 wrote:
| Not sure if this is mentioned somewhere, but it looks like a fork
| of the lite editor, also built on top of SDL and Lua.
| mdaniel wrote:
| https://github.com/pragtical/plugins/commit/54096a6461f5c034...
| makes me long for The One Grammar To Rule Them ™
|
| 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 _even worse_
|
| I had high hopes for Tree-Sitter since it seems to have really
| won mindshare, but the idea of having an _executable_ grammar
| spec[6] is ... well, no wonder it hasn 't caught on outside of
| that specific ecosystem
|
| 1:
| https://github.com/rspec/rspec.tmbundle/blob/1.1.12/Syntaxes...
|
| 2: https://github.com/JetBrains/intellij-
| community/blob/idea/24...
|
| 3: https://github.com/github-
| linguist/linguist/blob/v7.30.0/lib...
|
| 4: https://github.com/microsoft/vscode-textmate
|
| 5:
| https://github.com/highlightjs/highlight.js/blob/11.10.0/src...
|
| 6: https://github.com/tree-sitter/tree-
| sitter/blob/v0.22.6/test...
| emrah wrote:
| > light weight
|
| Honestly that's not an issue, I would personally not base my
| judgment on memory usage, unless it is a memory hog.
|
| 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.
| unregistereddev wrote:
| > 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.
|
| Please don't pass judgement on my preferences or whether they
| are practical. IntelliJ uses multiple GB of ram. Teams uses
| most of a gig. My browser uses a couple gigs. Docker containers
| eat a lot of it. When I am multitasking and everything is a
| memory hog, I'm forced to choose between using lighter-weight
| tooling and continually opening and closing apps. Using
| lighter-weight tooling is the practical choice.
| max_ wrote:
| 3.5 MB is great news, I am happy it's not another electron
| editor.
|
| I will be trying this!
| hollerith wrote:
| 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.
___________________________________________________________________
(page generated 2024-08-20 23:00 UTC)