Johannes Altmanninger

> Hmm, for bash, if I do `ls $HOME/`, I don't get completions either. I do get them on bash 5.3.3, even in "bash --norc -x" > I'd be fine...

> Should "${VARIABLE}" and "$(COMMAND)" be considered for inclusion > as part of the fish language to be more friendly to bash/zsh users? I think advantages are - compatibility (muscle...

amazing find, I can reproduce. I'll disable the fish_config.fish test in CI now, to reduce noise. > From my understanding, this is caused by the kernel buffering the > stdout...

> I tested this with bash and zsh, and both had no problem > [...] > So perhaps there is a way to handle this, as we don't need to...

> When we notice that the child has quit, we nonblockingly try to read from the pipe fd (and > process the read data). As long as we do read...

I wonder where's the deadlock. Maybe `builtin wait` gets stuck waiting for all 20+ processes to finish. Adding some debugging (`flog!()` or `dbg!()`) to `wait_for_completion` should show how many processes...

Right, it is always surprising when rustfmt completely gives up because of a weird comment position etc. I haven't looked at the details but I imagine we could maybe add...

Ok so we don't want to skip entire match statements. > it makes sense to move the comments to allow the formatter to actually > format, and deal with the...

> While it doesn't help with comments in places rustfmt can't handle, > it might make sense to update to `style_edition = "2024"` even > without a MSRV that supports...

> } || { > comment!(r#"matches options like `-f` if `f` is not a valid shortopt."#); > !self.strict_long_opts && !self.shortopts.as_char_slice().contains(&arg.char_at(1)) > }; I realized we can do the same but...