Rebuild terlar prompt as a configuration of fish_git_prompt

[faho]

Description

The terlar sample prompt uses its own git prompt implementation called __terlar_git_prompt, which was always a bit cheesy and meant that it was harder to adjust than other prompts.

This rebuilds that function as a wrapper around fish_git_prompt that just sets some variables.

To do so it adds two features to fish_git_prompt to achieve parity:

• The clean state char will now be used even in non-informative mode, it just won't be set by default then (this uses the actual informative mode setting, not even the informative chars setting)
• The branch can now be colored differently when it is dirty or something is staged

Note that this doesn't remove the __terlar_git_prompt function because that would break every configuration that currently uses the terlar prompt, which is quite awkward. If we wanted to remove it we would have to figure out how to tell users to switch. (which isn't too much to ask, all they'd have to do is copy the sample again!)

Part of #7884.

TODOs:

• Changes to fish usage are reflected in user documentation/manpages.
• Tests have been added for regressions fixed
• User-visible changes noted in CHANGELOG.rst

[faho]

(needs some more testing)

[krobelus]

Huh deleting it twice won't trigger another handler, right? Unless there is a spooky universal variables around...

(Re the commit message: the variable handler behavior for variable overrides seems correct as far as I can tell)

[faho]

Oh this is a rebase artifact (I did this for #7926 as well).

(Re the commit message: the variable handler behavior for variable overrides seems correct as far as I can tell)

The problem is that the handler only triggers when the override goes into scope, not also when it goes out of scope. So since we disable informative mode stuff when the variable is erased, we don't notice when it's used as an override.

See:

> set -l foo bar
> function on-foo --on-variable foo; echo on foo: $argv; echo foo is $foo; end
> foo=banana echo bar
on foo: VARIABLE SET foo
foo is banana
bar

See how the handler is never triggered for foo being "bar" again? That's the problem here.

[faho]

I'm not entirely sure how this should act, just saying that it gets in the way here.

[krobelus]

That sounds correct, because the override acts just like begin; set -l foo banana; ...; end

[faho]

That's consistent, I'm not sure it's correct.

Maybe we should fire the variable handlers when it goes out of scope? Or would that massively slow down block closing?

[krobelus]

I guess this problem has just never come up before because variable handlers are primarily used on global/universal variables.
Firing the handlers seems useful here - for running the git prompt with different configurations via variable overrides.
For this use case it's enough to fire handlers when a variable, that shadows another variables, goes out of scope; not when a local-only variable dies.

(Ideally we don't need the caching logic of ___fish_git_prompt_init, but it's probably a worthwhile optimization).

[krobelus]

Sounds great! I think it's okay if there are minor differences.

[faho]

I'm not currently working on this - there's some annoying subtleties that I don't have the right frame of mind to work on atm, so I'm moving it out of the 3.3 milestone.

[faho]

Yeah, closing for now. If I ever get back to this I can just reopen it, no need to keep the draft around.