The one problem I have with the trusted files thing is that I have no way to trust non-file-visiting buffers. Why is *scratch* untrusted!? *scratch* should always be trusted, without me having to configure anything, ideally. Though a setting to automatically trust non-file-visiting buffers would be nice.
I just ended up stopping using the scratch buffer because of that issue.
Right, the fact that the initial scratch buffer is untrusted is a bug AFAICT.
I'm considering adding a workaround to this issue in trust-manager, although ideally it should (also) be solved upstream.
Do note that I only configure this for `lisp-interaction-mode', which in practice really only gets used for the *scratch* buffer. But there are a few other instances in core that also use it, and if that concerns you, you can extend the above snippet with a check like
In practice this should also work. Do keep in mind if you just add this to your init.el then this will not persist if you re-create the scratch buffer.
If we are already experimenting with different ideas, this should also work (and gives a hint of how you want to fix the issue upstream):
I have the opposite experience. I have no trouble navigating Gnome apps, and now when selecting an application for a task, I'll choose a Gnome or GTK4 one first. Other apps implement odd controls that don't mesh with the rest of the system.
Most of the deadlocks I've faced are with different proccesses/devices both waiting on reads from each end of a socket/uart/etc. I've taken to putting timeouts on read calls, though then you have to deal with legitimate long request cycles timing out.
I have anecdata from my gamedev work that people tend to make mistakes when threads are pinned to some CPUs. Normally, when only time is a variable people can understand what can happen in their code. What confuses them is that space where those threads execute can be already taken. If a thread that should make whole system progress fails to grab a time slice these deadlocks are hard to reason about. Granted that lock ordering is the basic technique and if system did not had it all bets are off.
A pedestrian shouldn't need to be able to hear to be safe from cyclists. Focusing on headphones is ignoring that the same dangers are being imposed on deaf people and people with otherwise bad hearing. If a cyclist needs to use the bell for safety, they should hit the brakes.
These days, I've noticed that lobsters feels a lot more genuine to me, like hn was a few years ago. These days it feels like hn is bland and homogeneous, which I suspect is due to LLM-written comments.
Moving mostly to codeberg was a simpler affair than I expected. It's been a breath of fresh air. Its like github without the gamification, ads, copilot, and social features.
Its possible to dislike Rust but pragmatically use it. Personally, I do not like Rust, but it is the best available choice for some work and personal stuff.
Personally I think most programming languages have really ... huge problems. And the languages that are more fun to use, ruby or python, are slow. I wonder if we could have a great, effective, elegant language that is also slow. All that try end up with e. g. with a C++ like language.
Honestly I find writing Rust more fun than writing Python. Python just doesn't scale, any non-trivial quantity of it has a habit of turning into spaghetti however hard I try to be disciplined.
Rust, although annoying at a micro scale, does at least enforce some structure on your code, although like Kling I miss OO.
AI has made Rust approachable to a new audience of programmers who didn't want to dedicate their life to learning the ins and outs of the language. Especially for C++ developers who already learned the ins and outs of a hyper complex programming language and don't want to go through that a second time.
Before AI, writing Rust was frustrating experience that involved spending 90% of your time reading documentation and grumbling that "I could do this in 5 minutes in C++"
Now I can write Rust in a way that makes sense to my C++ addled brain and let the AI do the important job of turning it into an idiomatic Rust program that compiles.
Its for the time being is stuck with LLVM, so I can't currently LTO with GCC objects. Its got a lot higher complexity than I perfer in a language. A lot of features I find important seem perma-unstable. Pin is unnessesarily confusing. No easy way to define multiple compilation units for use with linker object selection and attribute constructor. The easy path is downloading binary toolchains with rustup and not using your disto package manager. You can't use unstable features without the bootstrap env var on distro rust toolchains. Cargo leads to dependency bloat. The std/core crates are prebuilt binaries and bloat binary sizes. Bindgen doesn't translate static inline code. The language has a ton of stuff it exposes just to std and not user code. Unsafe code is unergonomic. No easy way to model a cleanup function that needs more args. No support for returns_twice. No ability to use newer stuff like preserve_none. Can't go-to-definition from a bindgen binding to original header file. Macros pollute global namespace. Can't account for platforms where size_t and uintptr_t are different. Traits can only be relied on if marked unsafe. Can't implement something like defer since it holds a borrow. no_std code still can pull in core::fmt. Can't enforce dependencies are also no_std. Panics are considered safe. No way to add non-function fields to dyn vtables. No way to declare code separately from definition. No way to have duplicate type definitions that merge, making interop between different bindgen generated modules annoying.
reply