You can change the colors there, and it does work as well.

Thanks for the correction. I must've overlooked something when looking at how the preferences are loaded. :)

Could you explain to me how you went about approaching the issue?

At first, I looked into Thunderbird's source code and tried to simply identify the element that I could use in userChrome.css. I found that the element is called #messageEditor in messengercompose.xhtml. However, this doesn't work because the editor textboxes are apparently iframe-like things that load another website inside them (probably to prevent copypaste injection attacks or something). Even if I added * {background-color: red} in userChrome.css, it couldn't match the textbox.

I figured out the userContent.css way when I opened the debugger in Thunderbird's developer tools and set a breakpoint in the script that manages the textbox. For example, here's how to find it for the new calendar event editor:

So the calendar editor lives inside about:blank. However, about:blank is used in lots of places, so it would be good to add some extra conditions instead of changing the background of all about:blank pages used throughout Thunderbird. Luckily, the above picture shows that there's a link element that can be used as an extra condition like this:

@-moz-document url(about:blank) {
    html:has(link[href="chrome://messenger/skin/shared/editorContent.css"]) body {
        background-color: red;
    }
}

The tricky part is finding the right code to put a breakpoint into. It helps if you have a local copy of the comm-central source code files (as instructed in Thunderbird docs), since it includes XHTML files for digging around. The new calendar event window is in the somewhat logical path calendar/base/content/item-editing/calendar-item-iframe.xhtml, and the related scripts are right next to it in calendar-item-iframe.js.

Very few languages (or programmers!) are able to check that a function doesn't have side effects. In particular, checking that a function doesn't diverge generally requires a proof assistant, like in F* and Lean.

Your definition of functional programming is as valid as any, but it's so strict that even Haskell would be mid-tier in the functional ranking.

I didn't really understand the details of what you're making, but if you want to generate a random variable with entropy x, the straightforward approach would be to use Σ = { n | 1≤n≤⌈2^x⌉ } as the alphabet and start with a uniform distribution (which overshoots the entropy target) and slightly skew the distribution to reduce entropy to hit the target x. Then you can map Σ to your desired set (f64 or Vec in your case?) using an injection, since that preserves entropy.

Love it. Great lesson on why applicative exists, how it would/should look in C++ and discussion on prior/ongoing proposals.

I would call those language-specific. While they are useful in more than one language, they are also replaced by language features in many languages.

• Builder pattern can be simplified with kwargs (Python, C#) or argument objects (JS, C++).
• Factory pattern can be simplified with first-class types (Lisp, Haskell).
• Visitor pattern is similarly simplified by first-class functions (supported by most languages nowadays).
• Dependency injection of concept X is generally simplified by first-class X. I think the least widely supported is dependency injection of effects (Koka).

Design patterns are typically just workarounds for the limitations of the chosen programming language. What you might consider a pattern in C might just be a simple language feature in C++, and the patterns in C++ (as popularized by GoF) might just be language features in Lisp/Rust/whatever.

So rather than thinking about patterns, you should first choose the right language for the task. If you're working on a parser, you might prefer Haskell. If you need formal verification, there's C and Idris and little inbetween. If you need to hire lots of developers, something widely-known like JS might be the choice.

After you've chosen a language, you can identify the things that the language is bad at and apply the appropriate design patterns. Sometimes the patterns can be found in books (C++, Java) and sometimes it's just tribal knowledge (D).

I appreciate that the talk focuses more on automated approaches to safety this time. I feel the past years' talks were much more focused on goading developers to follow core guidelines, which doesn't really work in industry.

I personally don't like the idea, because keeping services entirely disconnected is good for privacy.

Furthermore, I think it's funny that the author used Matrix as an example of a service benefiting from chat federation, when Matrix is about to be deportalled from Libera.Chat due to bad UX and leaking secret channels. If Matrix can't even federate properly with IRC, there's no way they can do it with modern services like Discord.