Yeah they do. Run `wsreset.exe -i` in powershell and it'll install the Windows Store after a few minutes.

Notably, the do not reverse the course on the selling of user data. This is still a non-starter Mozilla. Do you not realize who your core base is? The only people who still use Firefox are people who value privacy and extensibility in our tools. Still a "no" from me dawg

I have 14 years experience and I've never seen anything like the job market for the last 1.5 to 2 years. In the past, when I was looking for a job, I'd have interviews scheduled within the first few weeks of looking. Nowadays any time I put feelers out I get nothing in response.

How is a large swath of the population okay with things like this? How do they not see such things as embarrassing on the national level? I just don't get it.

Hi there, I think I might have found a typo in your example class in the github README. In the class's `workflow` method, shouldn't we be `await`-ing those steps?

Nice catch. Fixing it :)

Not OP, but prettier doesn't break template literals, but it will break non-literal sections of template strings. For example, if we wrote this:

    const foo = `aaaaaaaaaaaaaaa${bbbbbbbbbbbbb}ccccccccccccccc${ddddddddddd}`;

prettier would fix it to

    const foo = 
      `aaaaaaaaaaaaaaa${
        bbbbbbbbbbbbb
       }ccccccccccccccc${
        ddddddddddd
       }`;

(or something similar) and it would be fully equivalent.

I don't like it doing that either tbh but hey prettier is good enough in most cases its worth putting up with it

I have a PR fixing that specific issue: https://github.com/prettier/prettier/pull/15209

Just needs another maintainer's stamp.

> backed off WEI

for now

> I’m still not exactly sure what the difference between useMemo and useCallback is

    const useCallback = (fn, deps) => useMemo(() => fn, deps);

That's it. That's all it is. `useCallback` is a shorthand for `useMemo`, when you want to memo a function definition.

Example:

    const handleButtonClick = useCallback((event) => {
      event.preventDefault();
      window.alert(`Hello, ${name}!`)
    }, [name])

is just shorthand for

    const handleButtonClick = useMemo(() => (event) => {
      event.preventDefault();
      window.alert(`Hello, ${name}!`)
    }, [name])

correct, but with useCallback you don't take an additional perf hit for redefining the inner function on every render.

useCallback is for callbacks, useMemo is for memoized data.

So basically you want something like how typescript does, where you can do this:

    const config = {
      rootDirectory: "/tmp",
      shouldFrobnicate: false,
    }

I'm far from a python expert, more like a TS dev who occasionally tries to write Python, but when I'm in that situation I find that writing one-off classes seems to be python's way of doing things. I'm not a super big fan of it myself, but it works:

    from dataclasses import dataclass
    
    def _create_config():
      @dataclass(kw_only=True)
      class Config:
        root_directory: str = "/tmp"
        should_frobnicate: bool = False
      return Config()
    config = _create_config()

I experimented with making a decorator that could do something like this, but never got it working with `mypy` so I gave up:

    @iife
    def config():
      @dataclass(kw_only=True)
      class Config:
        root_directory: str = "/tmp"
        should_frobnicate: bool = False
      return Config()

the `@iife` would make it so that `config` was a variable, not a `def`, but yeah the whole thing stank so I gave up

> Some individuals, particularly those running Linux, follow a standard called XDG Base Directory Specification. While Murex does not adhere to this standard, instead conforming to the de facto standard defined by the past precedents of previous shells, in order to offer flexibility for those who do prefer the XDG specification Murex does support overriding its own default paths via special environmental variables.

no no no you're missing the point: on POSIX systems, go with XDG by default. cmon guys it's 2023 not 2003

Murex doesn't just target POSIX systems and XDG added a lot of edge case problems I wasn't prepared to deal with at the time. Particularly so back when the shell was first created. So I went with the de facto shell standard instead.

You can override that behaviour if you want to use XDG but making it the default could break backwards compatibility, result in confusing documentation for non-POSIX users and introduce a lot of additional development and testing just to fix something that already works fine.

Like with any open source project, if someone else is willing to commit some time into solving these concerns then I'll gladly merge it. But I need to be pragmatic with how I prioritise my development time.