This tried migrating old abbreviations *twice* - once from the 2.3
scheme to the 2.4 one, and once from that to the 3.0 scheme.
Since this is purely for upgrading from fishes < 3.0, and basically
untested, let's remove it.
If anyone does that upgrade, they'll simply have to reexecute the abbrs.
We detect one terminal (foot) with a "string match" command, and all others in a long "test"
command. Let's put the detection of each terminal on a new line. This should be easier to read
and change. It also allows to lose one level of indentation.
This was an undocumented undunderscored function that wouldn't be
super useful to actually use manually (because it still checked if the
variable was set!). It also relied on `__init_uvar`, which was only
set in `__fish_config_interactive`.
Additionally it didn't remove any complexity because this was all very
simple "do thing a, do thing b, do thing c" stuff. It added a layer of
indirection instead, and made fish startup dependent on another
function.
If you want to reset your colorscheme to the default, use fish_config.
- Use named colors instead of hex values - not sure how this
happened in the first place, these all map to basic named colors.
- Reinitialize if these were last set on fish <3.4, new variables
have been added.
- Break this into a separate function for the sake of
__fish_config_interactive complexity, and allow for running
manually.
From my checks (gnome-terminal with the "gnome light" colorscheme)
this seems to be the only color that's barely visible in a light
terminal, and it's the only color mentioned in both bug reports.
I'm leaving the artistic decisions to others, this is now *acceptable*
in both.
Note that, because we use universal variables here (hint #7317), this
will only be changed for preexisting installations when the user
reloads the colorscheme.
Fixes#3412Fixes#3893
This was a handler for various prompt variables that called a repaint.
Unfortunately, if you set one of those *inside* the prompt (a logical
place for it), this would lead to something like #7775.
So, because this isn't actually *useful* as far as I can see (how do
you set these variables in a way that you're not already inside a
prompt or about to draw a prompt? in a key binding?), we remove it,
like we removed the repaint from git's variable handlers.
In this context, as it stands, $last_pid will give fish's pid (because
of pgroup shenanigans).
Since that doesn't really work, just `disown` without and let fish
figure out what the last process was.
Theoretically this has an issue if someone started a background
process *before* the python script *and* that exits before we run
disown.
That's a vanishingly small window and this is only run on first start,
so it seems acceptable.
Fixes#7739.
Over in https://github.com/wez/wezterm/issues/115#issuecomment-765869705 one of my users noted that fish had automatic OSC 7, but that it wasn't enabled under WezTerm.
You can detect WezTerm through the `$TERM_PROGRAM` environment. In practical terms, all versions of wezterm in the wild support OSC 7 so a version check is not needed.
I'm not a fish user myself, but I did give the equivalent change to this a try on my Fedora 33 machine (it has an older version of fish).
I can see in this file that there's some stuff with `__fish_enable_focus` that you may also want to enable under wezterm; the escape sequence is supported as are panes, tabs and windows.
As mentioned in 5b706faa73, bare
`disown` has a problem: It disowns the last *existing* job.
Unfortunately, it's easy to see cases where that won't happen:
sleep 5m &
/bin/true & # will exit immediately
disown # will most likely disown *sleep*, not true
So what we do is to pass $last_pid.
In help especially this is likely to occur because many graphical
browsers fork immediately to avoid blocking the terminal (we only
added the backgrounding and disown because some weren't).
Note that it's *possible* this doesn't occur if used in the same
function, but I don't want to rely on those semantics.
It might be worth doing this as the default - see #7210.
It also reflows.
We might want to think about doing something more extensible here, as
konsole is also about to add reflow, but for now the main problem
children here are VTE and alacritty.
Extends #7491.
This could lead to an infinite loop (well, stack overflow) because
fish_command_not_found would also be defined to call
__fish_command_not_found_handler.
Since this is for
- missing command errors
- when downgrading
we can just remove it.
Previously, when a command wasn't found, fish would emit the
"fish_command_not_found" *event*.
This was annoying as it was hard to override (the code ended up
checking for a function called `__fish_command_not_found_handler`
anyway!), the setup was ugly,
and it's useless - there is no use case for multiple command-not-found handlers.
Instead, let's just call a function `fish_command_not_found` if it
exists, or print the default message otherwise.
The event is completely removed, but because a missing event is not an error
(MEISNAE in C++-speak) this isn't an issue.
Note that, for backwards-compatibility, we still keep the default
handler function around even tho the new one is hard-coded in C++.
Also, if we detect a previous handler, the new handler just calls it.
This way, the backwards-compatible way to install a custom handler is:
```fish
function __fish_command_not_found_handler --on-event fish_command_not_found
# do a little dance, make a little love, get down tonight
end
```
and the new hotness is
```fish
function fish_command_not_found
# do the thing
end
```
Fixes#7293.
This adds a "fish_greeting" function that prints the variable of the
same name.
In doing so, it makes $fish_greeting default to a global
variable (this is of little cost because of the `_` builtin)
This means that:
- We have fewer universal variables by default
- If we change the default greeting people will actually get
- it (unless they have a leftover universal, of course)
- If the user changes their language the variable changes with it
I really kinda hate how insistent clang-format is to have line
breaks *IFF THE LINE IS TOO LONG*.
Like... lemme just add a break if it looks better, will you?
But it is the style at this time, so we shall tie an onion to our
belt.
This reverts commit 1b0ec21773.
"Interactive" has multiple meanings here, one of them being "the whole shell" is interactive, which `status is-interactive` tests, and one "this interaction is interactive", which happens when `read`ing in a script.
Fixes#7080.
This is part of our (well, my) quest to spice up the default prompt.
In this case we color the host if $SSH_TTY is set, which is easy to
detect and helps draw attention to the host.
See #6398.
See #6375.
This variable holds an integer that resembles the fish version up to
that initializations were performed. It should be incremented whenever
some new initialization is required after upgrading fish. This should
not change the behavior for existing fish installations, except for a
minor message on installations that upgrade from fish<2.3.0.
[ci skip]
The colors are set in __fish_config_interactive before the prompt is
painted for the first time.
Also initialize the $fish_color_status for the (pipe) status, bump the
version for that.
[ci skip]
