my team was driving me insane with leaving console.log("here") all over the place in every pr, so now we have a “no console.log” eslint rule in ci.

I guess my answer is it depends on your team. good logs are different, but imo if they’re just debugging statements they shouldn’t even make it into the repo let alone prod.

if it’s just you, do whatever you want lol, performance is almost certainly not significant and most users should end up ignoring them anyway

well the language server plugins all run a binary language server out of sandbox so zed doesn’t really do anything safer in particular there either. no ide has solutions, solutions don’t really exist right now. it’s not a problem of features of the language as much as it is features developers expect in extensions. I suppose there is a hypothetical “the extension wants to make this change to this file, approve” type flow like AI tools have now, but that sounds unpleasant to use. it still doesn’t get around things like language servers being designed to run as standalone processes out of sandbox.

by audits I meant you individually go and read all the code of all the extensions you use. of course that’s impossible too, but that was my point

I can’t imagine a sandbox would help. what can an an extension do that doesn’t touch some arbitrary code that gets run? it could add a line to the middle of a giant file right before you run and remove it immediately after. even if you run the whole editor in a sandbox you do eventually deploy that code somewhere, it can change something inconspicuous like a url in a dependency file that might not get caught in a pr

the only solution is to audit everything you install, know all the code you run, etc. ofc that’s not reasonable, but idk what else there is. better automated virus check things maybe? identity verification for extension publishers? idk if there’s an actual solution

it legitimately is a neutral network, I’m not sure what you’re trying to say here. https://en.wikipedia.org/wiki/Generative_pre-trained_transformer

they are the first thing that comes up when searching “cursor” in both ddg and google, so I think they’re doing ok

not sure what you’re talking about but there’s two things here.

TRAMP is great and you can run the lsp on the remote machine without installing anything assuming the linters and lsp are already installed. for comparison, vscode remote downloads and runs a shim thing when you connect.

I use doom emacs at work for large codebases all the time and haven’t run into any problems. why does it only work for really small projects?

yeah that should just be a pip package instead, then install it any normal way

most things seem to have settled on this, but tabs are so much better for accessibility. programmers with bad vision can have trouble differentiating smaller indentation levels, while some of them just bump the font size up so high that 4 spaces takes up too much screen space. each one can set a tab width that is comfortable for them. https://alexandersandberg.com/articles/default-to-tabs-instead-of-spaces-for-an-accessible-first-environment/ has some good arguments

with a forced formatter and a configured editor there really isn’t any argument for spaces

4 to 5 added like 2 tags, but was fully backwards compatibile. the painful upgrade you’re thinking of was 3 to 4 where they basically rewrote, it but don’t have any tutorial content other than one of the main devs making an absurdly long series of walkthrough videos so it’s impossible to find the topic you’re interested in

json is fine as a serialization format for things that need to be text, but it’s not great as something that gets edited by hand.

not that I enjoy xml, but writing long strings in json is even worse. xml I can write multiline strings as a first class entity.

I can add a comment to an xml document, json I have to write something hacky like "//": "my comment" and hope whatever is consuming it doesn’t care.

there’s just as many problems with json parsers, since most but not all of them treat numbers as js numbers, which are basically floats. you can’t rely on an arbitrary consumer having support to parse ints above a certain size so you just have to make everything a string and hope.

json allows duplicate keys, but they get overridden by the last occurrence. you can’t round trip json without losing something. you can’t rely on just seeing a key value in json text and that being correct since there could be another later. doesn’t come up often but it’s there.

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

bc nu does everything pwsh does, but without the odd and verbose syntax. their exceptions and error codes are two different systems and don’t make sense by default. instead of making shell cmds easy to parse I find myself having to use dotnet versions of things, which would be fine if the syntax for that wasn’t so terrible. nu still feels like a unix shell for the most part.

pwsh has its place, especially since it’s default. I’ve written plenty of pwsh scripts at work for ci and the like. I can get over the verbose naming in a text editor. using it from a repl isn’t my favorite experience

I love alternative shells. my shell has been set to fish and zsh for about a year each, xonsh for a few years, and now nushell for a couple years, and I think that’s probably my ranking as well.

fish and zsh are both nicer than bash, but they don’t give you as much as xonsh and nu do. you get nice completion and configuration and such, but it’s still a shell when it comes to the programming tasks.

I don’t want just a shell, I want a programming language with a good repl that makes it easy to deal with commands. xonsh and nushell both do that.

my major problem with xonsh was that there was python syntax, and there was shell syntax. it didn’t feel great to interleave sh cmds and py fns. everything had to be parsed and then everything had to be formatted to go back into sh cmds. the standard library of sh cmds doesn’t really exist either. you either use the py version of libraries for paths/processes/whatever, or you call and parse the os version. the former seems like the intended one. I found myself having to find a pip package for whatever task.

nu solves all my problems with xonsh without sacrificing much. there isn’t really a split between nu commands and shell ones syntactically. parsing is easy, most cli things output data as lines, ascii tables, or have a json flag, and nu has nice ways to deal with all of those. nu commands generally work given a single element or a list or a full table if they make sense to. running a command on each element in a list and dealing with the output is easy as opposed to having to break your pipeline and write a for loop. they also have plenty of builtins and plugins so the things I generally want to parse are already done. ls returns a table, ps returns a table, I can pass lists into rm, etc. there’s community plugins for git so I don’t have to remember their syntax for searching for commits, I just query in nu. aws cli has a json flag so I can explore logs and such as nu data. and if I just want.

now downsides to nu. it’s not bash so you can’t just source whatever file that a command probably gives you, and there’s no source-bash like xonsh has, so you’re stuck translating it to nu. if it just sets env vars it’s not awful since you can just shell out to bash, but doesn’t work for more complicated. for things like python you have to make sure you use the correct tool to make your venv since builtin one doesn’t give you a nu file to load. not sure about support in other tools.

overall it’s great and not really that much learning, especially if you just use it like a shell to begin with. it’s not much commitment to try a new shell since you can still call scripts written in your previous one. I’d say try it and see how it goes