I want this one: Commit Masks
The rest. Sure, fine. Don't really care.
Features I'd like to see in future IDEs
11–20 of 59 posts
Re: Features I'd like to see in future IDEs
#12What 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?
This is essentially the concept of a "text object" from Vim. Historically, it was somewhat challenging to actually define text objects with the richness of behavior one might want, but now with Tree Sitter and LSP you can have this pretty much for any language or file format.
Re: Features I'd like to see in future IDEs
#13these 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).
Re: Features I'd like to see in future IDEs
#14I 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.
Re: Features I'd like to see in future IDEs
#15> 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.
Re: Features I'd like to see in future IDEs
#16> Coloration of Tagged Comments He mentions Jetbrains let you do this. I do it in vscode using the TODO Highlight extension.
In addition, Vim does it by default for many filetypes. And it's easy to add for ones that don't. Other editors/IDEs probably also have it – overall I'd say it's a common feature.
Re: Features I'd like to see in future IDEs
#17After 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.
Re: Features I'd like to see in future IDEs
#18All 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 often use `hi-lock-symbol-at-point` and related functions for colouring stuff ephemerally, you can persist them if you find something that you need all the time. Extensive guide at https://www.masteringemacs.org/article/highlighting-by-word-... (and of course many packages that expand on this).
iimage-mode does the image thing
Let me know when you implement commit masks in magit, that sounds handy :-)
Re: Features I'd like to see in future IDEs
#19The 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.
Re: Features I'd like to see in future IDEs
#20Hmmm, 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 see…
What do you do with proper multicursor?
I frequently use it when I need to make some structural changes to consistent code (block replace function name x, add trailing commas, etc). Not sure what more power I am missing.