I want this one: Commit Masks The rest. Sure, fine. Don't really care.
Features I'd like to see in future IDEs
31–40 of 59 posts
Re: Features I'd like to see in future IDEs
#32Emacs already let's you embed images in comments with iimage-mode
Re: Features I'd like to see in future IDEs
#33Emacs already let's you embed images in comments with iimage-mode
Re: Features I'd like to see in future IDEs
#34What 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?
Wasn't that one of the original ideas behind Light Table?
Re: Features I'd like to see in future IDEs
#35I 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.
Can you elaborate? Mature IDE's already customize the presentation of things like annotations or comments, inject inline hints, and provide alternate editors for things like XML, markdown, or established UI description formats, etc
Re: Features I'd like to see in future IDEs
#36I 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.
Saving files as syntax trees instead of code files / ASCII might also do that, but that's a level of abstraction nobody is ready for yet, because you need a tool that can translate to readable code everywhere. It kinda reminds me of EXI, a proposed XML transfer protocol that wouldn't bother translating the document to a readable text format but just transfer as binary, a set of 'events' like the SAX parser approach to achieve much more efficient transfer. I don't believe it ever took off though, it was conceived when JSON quickly became more popular. It was only mentioned once on HN [0] 13 years ago, with one point and zero comments.
Re: Features I'd like to see in future IDEs
#37I 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 notice this myself a bit when I switch from a fullsize monitor to a laptop screen.
Re: Features I'd like to see in future IDEs
#38I 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…
When I make some change for local dev only, I always press the "diff markings" in the margins of the file, and there select that it should go to my "local dev" changelist and not be a part of main.
This is a bit similar to git -p, but the devex is much smoother.
Re: Features I'd like to see in future IDEs
#39> 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
#40It 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!