this, evil is the real 4th generation vi

this is neat but also is a closed source extension. I use https://github.com/Wilfred/difftastic which doesn’t do quite as much and doesn’t integrate outside of git’s diff, but is still significantly better than nothing

that’s not a one letter template literal, that’s built in python syntax. it only has combinations of u r and f and no user defined option. f makes it templated

just stick a verification task in ci. if I have to check if the format matches the standard in a code review instead of reviewing meaningful things my time is being wasted

the codebase readability certainly suffers, and this isn’t the only case of shenanigans like this

found the following in our codebase the other day.

while(booleanFlag)
    return;

thhere wasn’t more in the loop body, that was it. the loop conditional does exist and it can hurt you.

or if you really wanted qt, using java qt bindings: https://github.com/OmixVisualization/qtjambi

linting config itself wouldn’t be defined there, and it would be verified in ci and such, but a setting to tell vscode which linter and extension it should use to show warnings would be.

modern languages may have their own way for configuration but they don’t have a way to bind it to the list of vscode tasks and define how to run a debugger, which is the part that gets stored.

it’s easy to go overboard with extension suggestions, but I don’t think adding an extension for linter used, extension for formatter used, and any languages used if there’s a definitive extension.

My team is split between visual studio, vscode, and I use emacs. we have config for both vs and vscode in our repos since it makes working on a new project so much nicer and means we aren’t just sharing editor configs through side channels instead. it doesn’t do anything to me if I have editor config for an IDE I don’t use in the repo, but it makes it easier for someone new to jump in with a sort of same environment immediately

but if there’s a bug I’ll know exactly which line to look at

that doesn’t sound right, it’s so much smaller if it’s just one line

source?

json doesn’t have ints, it has Numbers, which are ieee754 floats. if you want to precisely store the full range of a 64 bit int (anything larger than 2^53 -1) then string is indeed the correct type