Features I'd like to see in future IDEs

What I'd really like is an IDE that functions on objects of code and not text files, and diffs and merges thar similarly operate on the syntax tree of the code and not on whether there's an extra newline or not.

Like, code formatting, that's just an implementation detail. Why can't there be a thing to let two people edit the same repo with different formatting preferences without it causing merge conflicts?

Kind of surprised speed isn't listed in here or caching.

It annoys me to no end when auto-complete stops working as it waits on rust-analyzer to finish. Like you had a completed run before; just use that information while you re-compute it!

All of this stuff makes me go 'that should be possible in Emacs', with the exception of colouring tagged comments, which I think is possible in Emacs. I think that ghost/replay thing is possible using Sly and iterating through objects is possible in Slime and Sly.

I would like an IDE that saves files in a consistent format but displays the code in whatever style the user prefers. This shouldn’t be hard to do and would help version control a lot.

I was thinking about the commit mask thing recently but imagining it as a part of Git, or an extension.The project I'm on at the moment is a big legacy codebase that requires a bunch of dev-only code changes for:

- functionality (setting API urls; forcing certain screens to appear; overriding config values that come back from an XHR)

- quality of life (skipping delays; turning sounds off)

It would be great to be able to toggle and mix and match these patches locally without risking committing them. A combination of stashes and branches kind of works, but the ergonomics isn't great, especially when there are conflicts.

To make sure i don't push temporary local changes to production, I used to have a github workflow that rejected code that contained the word "TODO" or "console.log". This way, i could add TODO comments that actually need to be done before deploying. Now i'm usign github less but my deploy script does the check, and you can probably make a pre-commit hook with this, or pre-push

Commit masks remind me of that time I couldn't run a Java app because it assumed a specific classpath order, but the classpath order is random on each boot, and my randomized classpath makes the app crash.

I've also seen some development teams rely way too much on IDE plugins to get anything done. Horrible software architecture with a 45 minute start-up time, I shit you not. They paid a shitload of money on software licenses for a special JVM/IDE plugin combo that allows them to hotswap almost everything to avoid ever having to restart the app during development.

Oh, it's also pretty much impossible to launch the development version of the app with a stock IDE due to the sheer amount of runtime code modifications from IDE plugins the development version depends on. Great times.

Emacs already let's you embed images in comments with iimage-mode

The queryable expression thing is something I struggle with all the time in Rust. It's especially bad in that language because (unlike in e.g. Java or C#) there is no way to view the Debug representation of your types in the debugger, you just get the raw memory layout which adds a huge barrier to 'what is going on with this code?' and requires you to dig around through countless nested layers to understand it.

> Coloration of Tagged Comments

He mentions Jetbrains let you do this. I do it in vscode using the TODO Highlight extension.

The Ghost/Replay might have security implications. Often the objects in memory might contain sensitive information (secrets or just customer data). During a debugging session you are likely aware of that. But IDE saving the data beyond your control increases the risk for a leak.

Similarly what they called Commit Masks seems like an invitation for putting passwords into source code, which is a bad idea. Even if done just to check things real quick.

> Ghost / Replay

This is harder than it seems. However I have seen vscode users use `rr` recordings to even step backwards from a breakpoint. But it is gdb-based (i.e. not very platform independent) and is not displayed in a "ghost" like manner which would be neat. I think the first step is for runtimes to get better at recording replays.

I believe Commit Masks are actually a bad practice.

I am huge fan of having a EC2 machine in AWS and using VSCode remote SSH or anything similar for development. There are so many differences between cloud and local, that you either embrace it (develop in EC2) or try to wrap it into one more layer or abstraction (hello Docker) and still fail.

Hmmm, these are kind of boring? I've seen colored comments a few times, embedding images is also possible in Dr Racket and on TempleOS I'm pretty sure.

Where's all the fun stuff? Debugger features are neat, but outside of this these features just seem tiny and cute and not too exciting.

Even stronger support for structured Treesitter-based editing? (See eg. Helix), proper multicursor support (Helix), both already seem like black magic to me compared to what came before.

All of these are things he can find using a better IDE. No new or breakthrough we need for the next generations of IDEs.

After three decades in software development I can happily say that I can’t remember the last time I was stuck chasing data in some abstraction hellhole. It’ll never seize to amaze me just how much self-flagellation OOP enjoyers are willing to endure. I’m not sure I’ve ever even seen an abstraction chain go as deep aw the example in the article. Maybe in one of the projects I sometimes review when I do my side gig as an external examiner for CS students. Don’t get me wrong, I spent almost 5 years with the debugging tools in Visual Studio enterprise or whatever the ludicrously expensive version was called 10 years ago. These days I’m typically rocking some sort of console print while I hack away in nick with almost no debugging tools like a total psychopath. The main thing that has changed for me is that I almost never do abstractions, because, well, because you’re going to spend: “ intense hour-long debugging session only to realize you KNOW that some piece of data exists SOMEWHERE IN MEMORY”.

That being said, a lot of people are going to disagree very passionately with what the very opinionated paragraph I just wrote. So I think it’s fair to point out that I actually think the author brings up some very good points that IDE makers should take notice of. Well maybe not the TODO part… If IDE’s should do anything about TODO comments it shouldn’t be giving them a different colour, no, it should refusing to save them.

Future IDEs will be IDEs that (will try to) understand what the code and developer is trying to do. Clippy, but more like a smart and fast butler who only needs half a word to understand where you want to go.

My feeling is that such feature will whipe away a big chunk of existing and today's desired features.

these are already done or boring (colors comment tags both emacs and nvim do), depend on language spec (images in comments would really depend on the lang spec), depend on language runtime spec and debug info (searching through memory for some struct, replay), or just see lame or do not apply to most languages (commit mask - this might be partially doable at the git level).

I want this one: Commit Masks

The rest. Sure, fine. Don't really care.

Sounds like a job for Vim, written by an Emacs zealot.

Vmax? Yeah that sounds kinda cool actually.