Features I'd like to see in future IDEs
mordenstar.com
Features I'd like to see in future IDEs
1–10 of 59 posts
Re: Features I'd like to see in future IDEs
#2The 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.
Re: Features I'd like to see in future IDEs
#3What 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?
Re: Features I'd like to see in future IDEs
#4Hmmm, 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.
Re: Features I'd like to see in future IDEs
#5What 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?
> 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.
We really lost so much when we moved away from s-expressions in favor of... whatever adhoc stuff we do right now.
Re: Features I'd like to see in future IDEs
#6All 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.
Re: Features I'd like to see in future IDEs
#7What 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?
Maybe you're already aware of it, but there is difftastic [0], which is a syntax aware diff tool that can also be used with git. Its understanding of syntax is based on treesitter, so it works for most languages. Although I haven't tried, I think most IDEs should also be able to use it.
Re: Features I'd like to see in future IDEs
#8What 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?
So you want Lisp?
Re: Features I'd like to see in future IDEs
#9> Coloration of Tagged Comments
He mentions Jetbrains let you do this. I do it in vscode using the TODO Highlight extension.
Re: Features I'd like to see in future IDEs
#10What 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?
I think treesitter is getting us closer to this goal. Many programming modes in emacs now support treesitter, allowing syntax-aware movement operations, code folding, etc. Even where modes haven’t been set up, you can call “treesit-explore” I think for any language for which you have a grammar available and get an outline of the nodes.
Hopefully we’ll continue to see adoption in this space, as it makes it much easier to add syntax highlighting and other basic support for new languages, and it makes it so that any new functionality that operates via treesitter should work with minimal modification for any language.