Bold Edit: An editor written by power users
bold-edit.com
bold-edit.com
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.)
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 :)
>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...
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.
> Unique Debugging
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.
> you need to install Terminus
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.
> 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.
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.
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.