It's a common problem, which is why it's also a commonly solved problem. Sublime Text has been GPU accelerated for over a decade, there's multiple GPU-accelerated terminal emulators for all the terminal-based editors, VSCode is GPU accelerated, …
VSCode is only GPU accelerated in the same way every website is GPU accelerated - text rendering is done using the DOM. Every program on your computer is GPU accelerated in that sense.
I think slowly enough and have a fast enough terminal that it's never the bottleneck. My first modem was 300 / 1200 baud so even a janky wi-fi connection is just fine.
It is a legitimate thing now, if you can type more than a word per minute you'll notice that many apps are not able to keep up. The most common offenders seem to be Electron apps. IDEs sometimes struggle as well.
I wish we could just all agree that there are some people who don't notice slight lag, and people who genuinely notice and are distracted by it.
Of course it's fine to ask why something like this project exists if you don't know. But I feel like the discussions tend to outgrow that and end up at "I don't need it so why should anyone care".
> I wish we could just all agree that there are some people who don't notice slight lag, and people who genuinely notice and are distracted by it.
This is literally the first time I've ever heard of framerate/latency being a concern in a text editor.
I mean, I get that it's annoying when your machine is chugging hard and there's a half-second delay on every keypress. But generally that means that something's gone wrong and is thrashing the processor, not that your text editor is insufficiently optimized.
I know some people are more sensitive to framerate than others, in games and videos. Maybe there really is someone in the world who craves a solid 144FPS/5ms latency when editing code. But it's news to me.
The blog seems to have some more details and features: https://bold-edit.com/blog/wrote-my-own.html. The feature set does seem nice, will keep an eye for this, but likely that you will have to pry Emacs out of my dead hands :)
Yeah. Text editors constantly come and go. And that's no bad thing, but for those of us just wanting to edit some text: what do we do? The design goal of these projects is always to be better than what's currently available, which sounds great, and then, 5 years later, development has stalled, and the community is gone. Meanwhile Emacs is still going.
The features of this thing all sound decent enough, but there's no source code, and it doesn't run on Windows, and it doesn't run on macOS, and scripting is "coming soon" - I wonder if that scripting will end up even half as good as Emacs's programmability. I bet it won't.
I have been here before. And that is exactly why I continue to use Emacs, even though it is a bit weird. I bet I will still be using Emacs in 2035, and I bet this thing will be long dead.
But I don't especially want to switch text editor every 5 years!
Besides, the clock starts ticking from day 1, so if you want the full lifespan then you'll need to start using it while it's still half-baked and buggy and has no ecosystem to speak of. And that means you'll spend a lot of time using it when the goal of "better than what's currently available" remains firmly unrealized (for all that it may have some key item of interest that's caught your attention). Or you could start using it later, once things are properly going, and then I'd expect your experience would be a bit more like mine, before I finally bit the bullet in 2006 or whenever it was and sat down to teach myself how to actually use this Emacs thing, and you'll be finding yourself having to switch after more like 2-3 years.
Still, this is no immutable law of nature, as Visual Studio Code (9 years old) shows. And of course, Emacs and vim themselves - along with a number of other less famous FOSS options - would never have got this far if every editor automatically died off after year 5.
> and scripting is "coming soon" - I wonder if that scripting will end up even half as good as Emacs's programmability. I bet it won't.
For any application that intends to be scriptable, it's difficult to add scriptability on after the MVP.
The best approach is to build an MVP that takes commands, which means that scripting has to be there before any other feature, including modifying text.
his is why Emacs and Vim are so ergonomic to modify - the base system is a scriptable environment on which the editor was built.
IOW, if you're building a programming editor, you should be doing "create REPL, use REPL to create editor", not "create editor, then try to throw REPL on top of it".
> his is why Emacs and Vim are so ergonomic to modify - the base system is a scriptable environment on which the editor was built.
This is more an Emacs than Vim thing. GNU Emacs was scriptable from the start, while VimScript was added in Vim v5 (when Vim had been around for 7-8 years). Most of Vim was from the beginning written in C with a scripting language and plug-in system being afterthoughts.
I think the difference from other editors is just that these afterthoughts have still had decades to mature by now :)
That caught my eye. How do you people debug C (on Linux) ? I'm tired of switching constantly between Sublime and GDB. I know there's a GDB plugin for Sublime but it's a pain to configure.
I need to edit my code AND set breaks in the same GUI window. There is DDD but it's old and odd looking. Tried Kate also but for some reason didn't like it.
The only thing I needed to configure are the paths to the executables to debug and their command line arguments.
This is for LLDB, but GDB works the samé, set the type to `gdb`. https://forum.sublimetext.com/t/debugger-for-c/73001/5
There is termdebug for Vim (should be included in Vim package itself) which lets you have a fancy TUI/editor together with the full power of GDB console.
The normal workflow for this kind of thing in vim is that you set up some keyboard shortcut that suits you in your personal configuration. Most people aren't manually using command mode for things like this.
Have you tried setting up a build command in Sublime Text to run gdb? I find it a bit easier for cli stuff that depending on a plugin. The json config is rather simple.
He is getting a lot of hate there for not open-sourcing it. I noticed a very hostile environment for one-person projects that don't do everything open-source, while businesses aren't held to the same standard, and they are the ones that benefit the most. That's sad.
Hyperbole kills the meaning of words, to the point that people stop taking them seriously. You're doing a disservice to "malware" here. Yes, VSCode wants to know everything you do in that app, but it's not like it will keylog everything you do and steal your credit card.
That's no hyperbole. Do you know what a malware is? If you do, you know that a text editor that collects telemetry is a type of malware, period. There is no meaning discussing if they are logging every thing but if they can. If they can, it is a malware. They can.
It's not unfair. I have a different standard for proprietary payware and proprietary freeware. With the former, you know where you stand, but in my experience, the reasons for not releasing freeware under a FOSS licence are normally user-hostile, like baiting in users with a free product and charging money once they're hooked. I've been bitten too many times, so I don't tend to install proprietary freeware anymore.
It is a bit hard to follow the project. No github releases to watch, no RSS to subscribe to. I don't feel like trying it right now, but very well may in the future.
Is there some double blind study showing that people can tell the difference between a frame dropped at 144 Hz and not dropped, in the context of text editing?
There's a pretty large contingent of developers that follow the likes of Casey Muratori and Jonathan Blow who view such dropped frames and input latency spikes as a canary for "this software is written wastefully and without competence". It's not a terrible take to be honest: on a modern machine why on earth would a _text editor_ be unable to process frames upwards of 144 Hz? It implies a technology stack built on an unknowable jungle of wasteful dependencies.
In other words, I don't think it's per se about a couple of dropped frames here and there, it's about a plumage display to other engineers with the same values.
Why on earth a text editor might not update the screen at 144 Hz could be, say ... it draws the characters using individual putpixel operations in a canvas. Which would actually be a very simple dependency that could easily be ported.
I tried it. It's decent. I pulled up a Ubuntu 24.04 system because 22.04 didn't have the required library versions. I probably should have just installed the libs in a side location but somehow a new system felt like less typing.
This has potential. It is pretty fast and laser focused on editing source code + debug. I'm curious how it does on a giant code base.
58 comments
[ 3.8 ms ] story [ 108 ms ] thread>Fast 4K: Bold doesn't drop a frame on a 144hz 4K monitor, using <1 CPU core
I would think this would be owned by the whatever GUI environment you are in.
It's a solo developer, not a startup.
My requirements are simple enough, but apparently not profitable, since no one has built a product that ticks the boxes.
> Responsive: Input latency is <5ms, UI and GDB responds instantly
I can't say that I've ever considered frame rate when choosing a text editor.
5ms input latency is a dubious claim, what really matters is input to photon / end-to-end latency
And most of the animations, and layouting. So "only" all the performance hotspots.
> Every program on your computer is GPU accelerated in that sense.
No, not really. At least not on win32 and anything Linux/BSD-y, some toolkit( version)s can do it, but that by no means implies every program uses it.
Of course it's fine to ask why something like this project exists if you don't know. But I feel like the discussions tend to outgrow that and end up at "I don't need it so why should anyone care".
This is literally the first time I've ever heard of framerate/latency being a concern in a text editor.
I mean, I get that it's annoying when your machine is chugging hard and there's a half-second delay on every keypress. But generally that means that something's gone wrong and is thrashing the processor, not that your text editor is insufficiently optimized.
I know some people are more sensitive to framerate than others, in games and videos. Maybe there really is someone in the world who craves a solid 144FPS/5ms latency when editing code. But it's news to me.
No source so no-one knows what it's doing in the background.
Needs glibc 2.38.
That having been said, it looks lean and mean. I will keep an eye on it.
The features of this thing all sound decent enough, but there's no source code, and it doesn't run on Windows, and it doesn't run on macOS, and scripting is "coming soon" - I wonder if that scripting will end up even half as good as Emacs's programmability. I bet it won't.
I have been here before. And that is exactly why I continue to use Emacs, even though it is a bit weird. I bet I will still be using Emacs in 2035, and I bet this thing will be long dead.
(I bet based on the odds. Time will tell.)
Besides, the clock starts ticking from day 1, so if you want the full lifespan then you'll need to start using it while it's still half-baked and buggy and has no ecosystem to speak of. And that means you'll spend a lot of time using it when the goal of "better than what's currently available" remains firmly unrealized (for all that it may have some key item of interest that's caught your attention). Or you could start using it later, once things are properly going, and then I'd expect your experience would be a bit more like mine, before I finally bit the bullet in 2006 or whenever it was and sat down to teach myself how to actually use this Emacs thing, and you'll be finding yourself having to switch after more like 2-3 years.
Still, this is no immutable law of nature, as Visual Studio Code (9 years old) shows. And of course, Emacs and vim themselves - along with a number of other less famous FOSS options - would never have got this far if every editor automatically died off after year 5.
Nevertheless, my bet stands.
For any application that intends to be scriptable, it's difficult to add scriptability on after the MVP.
The best approach is to build an MVP that takes commands, which means that scripting has to be there before any other feature, including modifying text.
his is why Emacs and Vim are so ergonomic to modify - the base system is a scriptable environment on which the editor was built.
IOW, if you're building a programming editor, you should be doing "create REPL, use REPL to create editor", not "create editor, then try to throw REPL on top of it".
This is more an Emacs than Vim thing. GNU Emacs was scriptable from the start, while VimScript was added in Vim v5 (when Vim had been around for 7-8 years). Most of Vim was from the beginning written in C with a scripting language and plug-in system being afterthoughts.
I think the difference from other editors is just that these afterthoughts have still had decades to mature by now :)
I need to edit my code AND set breaks in the same GUI window. There is DDD but it's old and odd looking. Tried Kate also but for some reason didn't like it.
Which did you try? The one using DAP https://packagecontrol.io/packages/Debugger works the samé as with VS Code. But you need to install Terminus too for it to work.
What I'm after is the other way around : an editor around GDB.
It's not mentionned in the page. How would one know they need it ?This adaptér is used for GDB https://github.com/WebFreak001/code-debug#debug
Somewhere there is a mention of Terminus integration, practically it doesn't work without.
Bold 0.2 - An IDE with LSP, DAP and more : programming
https://www.reddit.com/r/programming/comments/1eupocr/bold_0...
https://www.reddit.com/r/programming/comments/1c8yhll/i_cant...
"I can't stand using vscode so I wrote my own". I suppose that explains the motivation and the intended audience.
We have very different definitions of "hate". I mean, some posts are mildly negative, but there's nothing there that could be described as hate.
Is there some double blind study showing that people can tell the difference between a frame dropped at 144 Hz and not dropped, in the context of text editing?
In other words, I don't think it's per se about a couple of dropped frames here and there, it's about a plumage display to other engineers with the same values.
This has potential. It is pretty fast and laser focused on editing source code + debug. I'm curious how it does on a giant code base.