it is nice to be able to plug your keyboard into a new computer and have all your shortcuts and layout set up though. I do that so I have the same layout and shortcuts on my personal and work computers regardless of os
brian
joined 2 years ago
no, there are dedicated keycodes for copy and paste, and you can bind them to whatever
ctrl v is convention for paste, but plenty of things (ex terminals) use that for something else. this is a universal (wrt the app receiving it) keycode that means paste. it lets you bind a key, or a keyboard shortcut, to the paste key and paste in any app. without this it isn't possible.
it doesn't even have to be a new programmable keyboard. there exist software key remappers for linux.
you could remap a mouse button to paste, you could remap ctrl v to always paste regardless of the app, etc., all in software, all not possible before.
it seems like a new version of this kind of thing pops up often enough, but it seems like the people making them have never heard of AppStream. like I guess managing webapps too is unique, but everything else and more support AppStream, along with existing gui managers like kde discover, gnome software, etc
they're putting large amounts of binary data in git lfs, which is what it was designed for. lfs does have some rough edges though. if I had something really heavy on binary blobs, ex a large game or similar, idk if I'd be using git either. he extrapolates way too far though, most use cases don't run into any of these problems
and storing all that in a separate db is insane, it's stuff that should be versioned with the code. it's likely being created at a specific rev for the current code, and it evolves with it. if you git revert or create a pr, it should be part of that. it's not like they committed built binaries or smth. there should be tools able to handle this. git could be one of them if lfs was less rough
gitea has had some organizational problems so a lot of people have been using forgejo instead, which is just a community fork of gitea plus some more features
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
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
idk if 2 users is fair, it may just be my circles but I see nixos mentioned more than almost anything else on lemmy/hn/etc in the past couple years
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, if you bind ctrl c and ctrl v to copy and paste keys, you can get the same behavior in terminals and other apps that have weird default bindings for ctrl c and v for historical reasons