Live data from Hacker News

I can't stand using VSCode so I wrote my own

bold-edit.com

121–130 of 186 posts

Re: I can't stand using VSCode so I wrote my own

#121

Earlier quoted context omitted.

You're not disabled yet . But you may want to care about this before your eyesight, motor accuracy, etc. start failing. It's not some big "disabled/not" switch - setting the font 1pt higher is accessibility, changing the colours is accessibility, being able to tab through fields consistently is accessibility, etc.

The idea that I might eventually become disabled still doesn't make it an essential feature. Disabled users are not a significant portion of the userbase of most software. Accessibility is an essential feature for a text editor in the same way that Linux support is an essential feature for Fortnite.

> Disabled users are not a significant portion of the userbase of most software.

Have I got news for you. https://www.disabled-world.com/disability/statistics/

> Currently, around 10% of the world's population, or roughly 650 million people, live with a disability.

> In countries with life expectancies over 70 years of age, people spend on average about 8 years, or 11.5 percent of their life span, living with disabilities.

Sure, not all of the disabilities will apply to using an editor. But disabilities overall are very common. A significant proportion of users of anything are disabled in some way - it just may not be obviously visible.

Re: I can't stand using VSCode so I wrote my own

#122
post #53
post #48

Earlier quoted context omitted.

Everybody who worked writing code in the 70s-90s is smirking at “wait over a second”. Back in the day, I used to go get my coffee, shoot the shit in the break room for a few minute, and come back to find my debug runs just starting.

Turbo Pascal was so fast in the 80s that if I saw a syntax error further down the page it was faster to hit "compile" and let the compiler move the cursor to the error than it was for me to move the cursor myself. It was a very special compiler and they don't make them like that anymore.

They still do. Lua is likewise extremely fast, and comes without bullshit mostly,

Re: I can't stand using VSCode so I wrote my own

#126
post #124

Earlier quoted context omitted.

Have you had a good debugging experience with (neo)vim? I'm the author

And same for Emacs, great LSP and DAP integration.

I heard someone say gdb works great with emacs but I never had a good experience with C++ in neovim. I asked friends and they all say they use a second editor to debug which is part of why I bothered to do this

Re: I can't stand using VSCode so I wrote my own

#127
post #120

On the flipside, I recently had to make some changes to a ~1.5GB XML file, like in the middle of the file. I had a sudden flashback to the Atom editor, which developers considered a 1MB XML file as "large", and hence it totally chocked on a 100MB one I tried once, crashing out after eating 8+GB of RAM. To my mild surprise, it opened in a few seconds, and while all the fancy checking stuff got disabled, basic syntax h…

You didn't mention which editor you were able to edit the large XML in. Just confirming, it was VSCode? Because that'd be amazing!

Yes, VSCode as of half a year ago.

Re: I can't stand using VSCode so I wrote my own

#128
post #53

Earlier quoted context omitted.

Turbo Pascal was so fast in the 80s that if I saw a syntax error further down the page it was faster to hit "compile" and let the compiler move the cursor to the error than it was for me to move the cursor myself. It was a very special compiler and they don't make them like that anymore.

The trick is to have language "optimized for compilation" and do not do fancy optimizations. Java is similar (but overall infrastructure around compiler makes it slow). Golang also quite fast.

I think LLVM missed the boat, on this, by being an early mover. A lot of the optimizations are resource-only analyses; the few that re not are "just" various levels of interpretation. That kind of implies we need a framework to define resource utilization and evaluation at the instruction/machine-code level with a standard API. Having an optimizer for an abstract IR is less useful.

The point being that compilers would then target emitting reasonable machine code at speed, and The Real LLVM would do analysis/transform on the machine code.

Re: I can't stand using VSCode so I wrote my own

#129

Earlier quoted context omitted.

In my experience, that one-second wait to run a binary that you just built is due to realtime scanning by Windows Security. It's not very bright. It sees a new .exe file and assumes you downloaded it from the Pirate Bay, even though it was written by link.exe. You can disable it as long as Group Policy doesn't dictate otherwise.

Not having an exclusion for a development directory is like using a 10yo machine or using a laptop without the power brick connected: it’s basically leaving half the perf on the table. Still, a second seems a bit much for a real-time scan.

Under Windows 11, a "dev drive" can also make a big difference.

https://learn.microsoft.com/en-us/windows/dev-drive/

Re: I can't stand using VSCode so I wrote my own

#130
post #11

I use vscode for doing devops-y things (Terraform, OpenTofu, JSON, python, yaml, txt, dockerfiles, etc.) and sometimes the way it bogs down my system drives me bananas. I'll punt to Sublime Text on occasion and use it for a few days, but then start running into papercuts in various places and have to go back to vscode. I so, so wish there was a better way to do this without fucking electron.

Keep an eye on https://lapce.dev/ and https://zed.dev/ . Both immature, but show a lot of promise! Also both open source, so (in theory, I haven't tried) you can contribute patches to fic your issues

Man, Zed gives me hope, but it's missing so many features and (robust) extensions. Monthly I'll open it and see if I can start working with it, but the day still has not come.
Post reply on HN