Johannes Altmanninger

> Really, what we want is to avoid showing too much prefix for too little "suffix". Good point, I agree that it's actually about the relative length > or to...

One complication is that fish needs knowledge of available command options to know what is the subcommand in a commandline like `git -c color.diff.old=blue diff`. The code duplication could be...

> If so, wouldn't that be solved by the --require-parameter option which can be specified when writing complete commands? Yes, you're right that would work. > I was referring to...

One problem is that it's not so trivial to detect the subcommand; it depends on the specific command, for example git --git-dir .git status I think this is the canonical...

Cool, I like your second approach with nested `--subcommand` flags. Perhaps `--subcommand-selector` should return the remaining args, so if the commandline is `git --git-dir .git status --porcelain` that's `status --porcelain`,...

I think we should fix this because the other behavior doesn't make sense. As you point out, truncating only at the end should results in incorrect evaluation of parenthesized expressions...

Hmm okay it's not so simple. The problem you are seeing is that `bc` (hence fish 2.x) use `scale` for the precision of all computations, whereas the new builtin `math`...

Adding `//` to builtin `math` sounds fine too.

> If --scale=0 worked the way it does in bc there wouldn't be a need for //. Also, // is only of limited help if the rest of the calculations...

When reverting bae75c96d945504ff1e13464149175135e402a4f and allowing files: ```diff diff --git a/share/completions/unzip.fish b/share/completions/unzip.fish index fe513b87c..cfd58b857 100644 --- a/share/completions/unzip.fish +++ b/share/completions/unzip.fish @@ -41,7 +41,7 @@ if unzip -v 2>/dev/null | string match -eq...