![](/static/23fb711/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/c0ed0a36-2496-4b4d-ac77-7d2fd7f2b5b7.png)
I’m both, I say fuck all the time. I fuck on and off the clock.
I’m both, I say fuck all the time. I fuck on and off the clock.
damn bleeding edge males
First guy looks really happy he forgot the BBQ tools.
Honestly, this is why I’m hoping the Vsuon Pro doesn’t flop. It really feels like it could open the door to a new era. Of course, that’s still years away, but you’ve got to start somewhere. Better now than never.
They’re both pretty on par for the most part. If it’s too much of a hassle, there’s no real need to switch.
Now that Gitea is owned by a for-profit company, people are afraid that they’ll be making anti-user changes. This, Forgejo was born. It pulls from Gitea weekly, so it’s not missing anything. It’s also got some of its own features on top, but they’re currently pretty minor. Also, most of the features end up getting backported back to Gitea, so they’re mostly on par with each other. However, many features find themselves in Forgejo first, as they don’t have the copyright assignment for code that Gitea does. Additionally, security vulnerabilities tend to get fixed faster on Forgejo. They are working on federation plans, however, so we’ll see how that pans out.
Overall, there’s no downside of switching to Forgejo, and you’ll probably be protected if Gitea Ltd. makes some stupid decisions in the future. However, at the moment, there’s no immediate advantage to switching, so you can stick with Gitea if you’d like.
That’s fair. I started with what everyone was using at the time, which just so happened to be Neovim. I’m also too lazy to switch/try anything else.
Plus, I’m not sure if Neovim simply extends Vim functionality. I know it’s a fork, but the codebase has changed so much I’m pretty sure many newer features of Vim need to be manually added to Neovim. Inlay hints in the middle of lines is already implemented in Vim: as for Neovim, it’s not here yet (well, it’s coming in 0.10, but I don’t use nightly so I don’t have it)
I mean, I’d just bind vim to nvim. If you still want vim accessible, bind it to something else. I don’t really see any downsides to Neovim: it’s decently backwards compatible, enough to use most old plugins, with the advantages of Lua config and a much wider repository of plugins.
You are a nerd with too much time
Thank you for that information. I had no idea that command existed, I guess because primarily I’ve seen people sending patches over email. I’ve updated my original comment with additional information. Thanks for calling me out 😅
I mean, Git doesn’t natively have pull requests either…the “official” method involves sending patches through email. It seems that Fossil has a similar setup (although without the tool)..
PRs are a feature introduced by GitHub. I guess Fossil bundles would be close enough to them.
EDIT: I was wrong. Turns out Git does have a pull request feature. It requires you to upload your code to a public repository, after which it generates a message asking to pull, which can then be sent via any medium to the repository owner. It doesn’t require patches, or GitHub. Differences to note: these aren’t like GitHub/Gitlab/Gitea pull requests, where you’re given a simple web interface and have to merge from a repository on that instance. Your repository can be hosted anywhere using git request-pull
. You’ll most likely then send the request through email, and get feedback in the form of replies. If you push newer changes to that branch, you’ll have to request another pull, as request-pull
only specifies a commit range. But yeah, I guess got technically does have pull requests. (For the scope of OP’s question however, I don’t believe he meant this.)
Oh that’s smart! And then nushell just handles the data for you…I might try that!
Looks very cool! I’m very comfortable on Voyager, but I checked it out and my initial impressions:
No app’s perfect from the start, just my two cents. (Maybe I’m getting a little nit-picky? IDK, just my advice.)
I’ll point to how many functional languages handle it. You create a type Maybe a
, where a
can be whatever type you wish. The maybe type can either be Just x
or Nothing
, where x
is a value of type a
(usually the result). You can’t access the x
value through Maybe
: if you want to get the value inside the Maybe
, you’ll have to handle both a case where we have a value(Just x
) and don’t(Nothing
). Alternatively, you could just pass this value through, “assuming” you have a value throughout, and return the result in another Maybe
, where you’ll either return the result through a Just
or a Nothing
. These are just some ways we can use Maybe
types to completely replace nulls. The biggest benefit is that it forces you to handle the case where Maybe
is Nothing
: with null, it’s easy to forget. Even in languages like Zig, the Maybe
type is present, just hiding under a different guise.
If this explanation didn’t really make sense, that’s fine, perhaps the Rust Book can explain it better. If you’re willing to get your hands dirty with a little bit of Rust, I find this guide to also be quite nice.
TLDR: The Maybe
monad is a much better alternative to nulls.
I thought it was TS/JS too, but the way those braces are below the if statements makes it feel more like C#.
This is fucking cool. I can imagine the many times this could’ve helped me quite a bit, and honestly even if I didn’t find the function I needed I could still probably hack out a decent implementation in whatever language and actually contribute towards this. In 5-10 years, this could be really useful.
This comment was made by the trombone gang.
My code is beautiful.
My process wasn’t.
I already regret it, but I won’t stop.
I’m going to try it in Haskell.
Might Probably will regret this.
Don’t see it. Could somebody give me a pointer?