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
Features I'd like to see in future IDEs
41–50 of 59 posts
Re: Features I'd like to see in future IDEs
#42Emacs already let's you embed images in comments with iimage-mode
There needs to pe a standard that all editors understand. Propriatory answers like emacs don't count as some of us do not have the same editor religion.
Re: Features I'd like to see in future IDEs
#43Hmmm, 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.
One of the most powerful features of eg Helix is the ability to very smoothly and easily filter inside your existing selections, or to split them.
I think the focus here is on "selections", as opposed to just "cursors".
So for example, you can select all occurrences of X (say, usage of some global variable), then say "for each of these selections, select the whole function", and then say "select the name of the function".
And bam, this is a (somewhat artificial and forced example), but you assembled a list of all functions with a specific property in a few button presses without ever leaving your editor. This is very close to stuff I do all the time in Helix. This is a godsend when it comes to manipulating (for example) a huge array of JSON data.
Maybe this is all obvious to you, but this seems like the kind of thing that probably still feels like black magic to a lot of programmers, and which certainly hasn't reached all editors yet (most are not focusing on selection editing as a first-class usecase).
Re: Features I'd like to see in future IDEs
#44After 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…
I also don’t like OOP, but what does that have to do with digging through a large data abstraction? Sometimes it’s unavoidable, and the problem your solving naturally lends itself to a recursive data structure that ends up being very deep (basically any kind of tree data structure). A query language would be great for that, and trees are very common in all code, regardless of paradigm.
Re: Features I'd like to see in future IDEs
#45Commit 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.
Re: Features I'd like to see in future IDEs
#46What 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 feel that the problem is not text but language design. A great language should be close to a pareto optimum for both human and machine legibility. Most languages are optimized for human familiarity, which is definitely not the most machine readable format and probably not the most human readable (in a platonic sense). Being more specific, most languages, in my opinion, are far too permissive with whitespace and use…
Tooling that enforces strict whitespace/formatting rules is a huge pet peeve of mine. It breaks my iteration flow because I have to stop thinking at whatever abstraction layer I'm working at to deal with the minutiae of formatting. I dislike automatic reformats as well, for much the same reason I hate webpages that jump around after loading. Just let me see the code I'm writing without it whizzing off onto adjacent lines because I'm going back and forth over column limits.
Re: Features I'd like to see in future IDEs
#47What 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?
The helix editor [1] allows you to navigate and select code objects, I use Alt-o all the time which expand the current selection to the parent syntax node. As mentioned by sibling comments, there are also a bunch of diff tools that are syntax aware instead of operating on plain text. All of these are backed by tree-sitter.
Re: Features I'd like to see in future IDEs
#48What 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 feel that the problem is not text but language design. A great language should be close to a pareto optimum for both human and machine legibility. Most languages are optimized for human familiarity, which is definitely not the most machine readable format and probably not the most human readable (in a platonic sense). Being more specific, most languages, in my opinion, are far too permissive with whitespace and use…
an excess of syntactic sugar leads to cancer of the semicolon.
Re: Features I'd like to see in future IDEs
#49I want this one: Commit Masks The rest. Sure, fine. Don't really care.
IntelliJ pretty much has this; your can put changes into different changers sets, even within the same files.
Re: Features I'd like to see in future IDEs
#50Emacs already let's you embed images in comments with iimage-mode
TIL.