Live data from Hacker News

Features I'd like to see in future IDEs

mordenstar.com

31–40 of 59 posts

Re: Features I'd like to see in future IDEs

#31
post #11

I want this one: Commit Masks The rest. Sure, fine. Don't really care.

Your IDE likely supports changelists, Jetbrains by default or VSCode through an extension. I always create a changeList for local which doesn't get committed and even persists across branch switching, and as it's still partially in your git view I'd argue it doesn't hit the authors problem of forgetting the changes you made locally.

Re: Features I'd like to see in future IDEs

#34

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?

> an IDE that functions on objects of code and not text files

Wasn't that one of the original ideas behind Light Table?

Re: Features I'd like to see in future IDEs

#35

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.

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

Imagine you like two spaces and I like four spaces for indents. With the above idea we both get what we want, locally you see two spaces and I see four, and there's no diff for indents whenever one of us edits a file. Similarly for any other formatting preference.

Re: Features I'd like to see in future IDEs

#36

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.

That could be hacked together via some git hooks in theory, like, apply code formatter with your preferences on checkout, apply shared code formatter on checkin. But it's probably more complicated than that.

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.

[0] https://news.ycombinator.com/item?id=2312746

Re: Features I'd like to see in future IDEs

#37

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.

A while ago I talked with someone who was working on clang-format and they said they tried this (at Google, I think) and the results were not good: they found people write different code depending on the format. For example, code written to fit in 120 columns but then formatted to 80 columns will look worse than code written for 80 columns, due to minor variations in verbosity and variable names and what not.

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

#38

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…

I do this all the time in IntelliJ/JetBrains based IDEs, using the "changelist" functionality. I have "shelved" different patches I can bring forward, and they each appear in their own changelist. When committing it's from the main changelist, so never accidentally included.

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.

I often do it somewhat in Java code, by dropping the current frame/stack, and then going into it again fresh. As long as most code is written without sideeffects, it's very powerful for fast iteration combined with hot swapping code changes.

Re: Features I'd like to see in future IDEs

#40
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!

Post reply on HN