i dont use jetbrains products but you can map the command palette or the file search to double shift and have it function the same way. zed supports key chords for bindings perfectly well. just do "shift shift" and it should work
Default double shift in zed goes to Execute a command window, sadly it doesn't support file searching within the same window and that's what I suppose he meant. I know cause I'm an avid JetBrains fanboy too and I can't use any other IDE because of that and few other features. Also, they're working on Search Anywhere Jet-Brains style feature right now if you believe Github Issues.
I use the (now deprecated?) opus plan mode still. Sonnet 4.5 turns in less thought out plans than Opus.
I wish codex cli tool wasn’t so super basic. Not even dedicated plan mode. Very annoying how hard the models are tied to their specific CLI tools.
It's not so much about the price, as the horrible reputation they've built on leaving customers out to dry and ruining vacations with no recourse. Amex is an exception here. But even the slightest possibility of being hit with "sorry we don't have you in our system, you'll have to call Expedia" makes it a nonstarter for me after dealing with it.
I found setting up complex train networks in factorio pretty annoying. Your less than ideal designs can’t really be modified in dense areas without tearing up half the factory. I ended up just trying to chuck signals at the problem but every 20 mins or so the timing of the trains would deadlock.
Very excited to see all the new tools and combinator logic controls. It seems like a whole new bag of tricks to deal with train issues.
Now that things will be multi planetary, I am wondering how we will deal with biter/scheduling issues when off planet.
The factory has an entirely different scale with the trains, and adapting to that is difficult in refactoring the factory. I think on new playthroughs I'll build out to a train oriented factory, moving new production units further away and transporting more by rail
Ruby meta programming is awesomely powerful, but also one of the main reasons I never want to work in another’s Ruby codebase again. There is always some developer who read some article like this and invents their own DSL to solve a problem that didn’t need one. It’s pure pain to debug it.
Exhibit #1: rake's DSL syntax. It allows "neat" syntax abominations like
rule :name, [:param] => [:dep1, 'dep2'] do |t|
where every argument except the name can either be missing, single (value) or multiple (array). Sure, it has the "advantage" that it's syntactically valid Ruby code, but it then requires some 70 lines of awful code to actually parse that data into a usable construct: https://github.com/ruby/rake/blob/7b50e9dc37abc57fd365c16cb1...
I always have to look up the variations of that parameter passing when writing rake tasks, not sure that is such a good sign that it's a great design in the first place.
If you have some group that all understands and checks each other from the beginning, Ruby is probably great.
However it was every startups default choice for a while, and those code bases get wrecked and have no oversight until way later. A lot of bad ideas becomes foundational. This scenario is far more common than good Ruby code bases. It’s just easier to rule out Ruby when looking for new jobs.
I agree, but I wonder how people feel about Racket in this context, where the "language oriented programming" approach is common and the idea that you solve problems by creating a DSL is the norm.
I feel the same. For my own projects where it's only me working on the code it can be really nice, powerful and big productivity boost. But if you start having multiple people on the codebase it's not going to be fun to debug.
Even under an RTO mandate to a sinking ship, people will still go in. Who are are they going to run to? Nobody is hiring and paying the same rates unless your resume say AI.
reply