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.
> 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".
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.
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.
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.
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.
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.
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 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.
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 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.
Readit News
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.
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.)
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".
>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.
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.
Bold 0.2 - An IDE with LSP, DAP and more : programming
https://www.reddit.com/r/programming/comments/1eupocr/bold_0...
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.
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.
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 ?> 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.
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.
5ms input latency is a dubious claim, what really matters is input to photon / end-to-end latency