This is my thinking. Ctrl-Enter is usually "submit the form this input is a part of" in my experience, especially if you're in a multilinear text input (or textarea).
I don't want to presume your use case, but Ghostty has a command for dumping the buffer to a file, which I use for processing output "too late" to use grep.
Bitwarden has a desktop GUI app as well as an official CLI. If you're comfortable with it, there are also community ones like https://github.com/doy/rbw
Eh, maybe. There's a performance tradeoff here and maintainers opted for performance. I'm sure many folks would agree with you that it was the wrong choice, and I'm sure many folks would disagree with you that it was the wrong choice.
There are also specific methods for doing *erflow-checked arithmetic if you like.
The idea with rust is that you _can_ have safety with no performance cost if you need it, but depending on what you're building, of course, that may imply extra work.
The pragmatism of Rust means that you can use reference counting if it suits your use case.
Unsafe also doesn't mean throwing out the Rustiness of Rust, but others have written more extensively about that and I have no personal experience with it.
> The problem with Rust is that it tries to force safety but doesn't have good ways for devs to tell the compiler code is safe...that is a fundamental weakness.
My understanding is that this is the purpose of unsafe, but again, I can't argue against these points from a standpoint of experience, having stuck pretty strictly to safe Rust.
Definitely agree that there are issues with the language, no argument there! So do the maintainers!
> if I need to manage memory then I would look elsewhere atm
Haha I have the exact opposite feeling! I wouldn't try to manage memory any other way, and I'm guessing it's because memory management is more intuitive and well understood by you than by me. I'm lazy and very much like having the compiler do the bulk of the thinking for me. I'm also happy that Rust allows for folks like me to pay a little performance cost and do things a little bit easier while maintaining correctness. For the turbo-coders out there that want the speed and the correctness, Rust has the capability, but depending on your use case (like linked lists) it can definitely be more difficult to express correctness to the compiler.
I think this is true initially and Rust didn't "click" for me for a long time.
But once you are _maintaining_ applications, man it really does feel like absolute magic. It's amazing how worry-free it feels in many respects.
Plus, once you do embrace it, become familiar, and start forward-thinking about these things, especially in areas that aren't every-nanosecond-counts performance-wise and can simply `Arc<>` and `.clone()` where you need to, it is really quite lovely and you do dramatically less fighting.
Rust is still missing a lot of features that other more-modern languages have, no doubt, but it's been a great ride in my experience.
The core of this argument taken to its extreme kind of makes the whole discussion pointless, right? All the languages can do all the things, so why bother differentiating them?
To entertain the argument, though, it may not be a language issue, but it certainly is a selling point for the language (which to me indicates a "language issue") to me if the language takes care of this "library" (or good defaults as I might call them) for you with no additional effort -- including tight compiler and tooling integration. That's not to say Rust always has good defaults, but I think the author's point is that if you compare them apples-to-oranges, it does highlight the different focuses and feature sets.
I'm not a C++ expert by any stretch, so it's certainly a possibility that such a library exists that makes Rust's type system obsolete in this discussion around correctness, but I'm not aware of it. And I would be incredibly surprised if it held its ground in comparison to Rust in every respect!
I don't think I've claimed that ignoring the author's request is factually wrong. I'm debating on the internet because I _do_ believe the license makes more allowance than you give credit, but I definitely would not say that what I'm doing here is objectively "in the right". I've reached out to the author as a result of these discussions, because I do, in fact, value what you are referring to and believe I did make some false assumptions about what the author might have intended.
To say that the license doesn't supersede the author's words is your opinion. It does, in fact, supersede the request both in law and "socially".
If any requirement or request need be laid upon the software and its use, there are mechanisms for doing that available today and the author willingly chose to try something new. This doesn't negate their request, but it does bring into question the "social contract"; people have certain social expectations of software, particularly when licensed like this, that you seem to ignore or consider null in this argument, which seems unfair and one-sided.
I do believe that this situation is not as cut and dry and morally wrong as you seem to be stating. What of a user that deploys the project without ever reading that specific page of documentation?
Perhaps you and I are debating towards different end states here. Myself towards what a fleshed-out approach to this kind of permissive-license-plus-social-request open-source might look like and you towards ignoring the request of another human being implying an eventual complete breakdown in society.
It's simply untrue that every request from every human being (regarding something they have made or otherwise) must be respected and followed above all else and to think otherwise trends towards its own breakdown of society. Intent and requests are not the be-all-end-all of ethical cooperation that you seem to be arguing for. Does this imply that anarchy and chaos are the answer? No, of course not! As I have tried to indicate, there is more nuance here than your argument makes room for and indeed the lack of nuance in your own argument as you tighten it down further results in its own ethical problems which you seem to be trying to argue into impossibility.
Alas, we humans on an individual and group level will always have mutually exclusive goals and opinions and working through those is part of the human experience - relationships take communication, work, nuance, understanding, and compromise. Absolutism such as you are calling for is the kind of thing that results in societal collapse as well.
In summary, I agree with you that asking the author is the right thing to do here as I _did_ read the documentation thoroughly and I should have done so and not assumed that my little personal git forge was "exempt" from the request. As a result, I have reached out to discuss as requested. I also would say that anyone else that opts to interpret the license literally would also be in the right, though. I also disagree that this issue is as cut and dry as you make it out to be. I also believe the status quo around "open source plus restrictions" (if you can say there is much of one) can be greatly improved and is a discourse worth having.
I don't think its fully correct that social pressure means that permissive licenses are no longer meaningful when it comes to the ethics or sociology of open source software.
Since the original subject is also about swapping out the imagery, it's also difficult to take your argument too seriously as the term "exploit" is doing a lot of heavy lifting for your argument.
I will also add that the social and ethical component goes both ways: is it ethical to knowingly give something away freely and without restriction and then immediately attempt to impose restrictions through a purely social mechanism? I would say so as long as your expectation is that some might politely decline.
Or worse, some may respond with the same vitriol and then we're at your original point, which doesn't seem to be preventing such an approach here, making me doubt your hypothesis.