This indents continuations after pipes and conjunctions if they contain
a newline.
Example:
cmd1 &&
cmd2
But it avoids the "double indent" if it indented unconditionally:
cmd1 | begin
cmd2
end
More work towards improving #7252
Prior to this change, when emitting gap text (comments, newlines, etc),
fish_indent would use the indentation of the text at the end of the gap.
But this has the wrong result for this case:
begin
command
# comment
end
as the comment would get the indent of the 'end'. Instead use the indent
computed for the gap text itself.
Addresses one case of #7252.
fish's internal completion logic is much smarter than the globbing in this
function, so let's just reuse "complete -C", and filter directories and
files with the given suffix.
Thanks to @Kratacoa for reporting on Gitter.
Using "complete -C" works well no prefix is given. Since in this repository
only the openocd completions pass a prefix, I left the prefix-case as is.
It could probably be improved and simplified as well. The prefix argument was
introduced to avoid cd's side effects inside a completion. Using cd is tempting
though because it would allow to use the same logic as without a prefix.
It's useless - `expect` has a timeout anyway, and it defaults to 5s,
so these 0.5s sleeps just mean it'll always take at least 0.5s.
Sometimes it is useful to let things settle before *sending* text, and
it would be nice to be able to set the timeout for each expect
separately, but just adding to the timeout isn't useful.
This one sometimes fails with a zombie detected, so I'm assuming it's
too fast for reaping to happen, so we add another 100ms sleep.
Yeah, this isn't great but...eh
The ternary expression was causing the list of paths (e.g.
$fish_function_path) to be copied. Avoid that copy with an if statement.
This reduces the time spent in try_autoload from 2.4 sec to 961ms on
the seq_echo benchmark run 1024 times, about 5% improvement.
Oh, C++...
"repaint" here is a bit of a misnomer. It *doesn't* re-highlight, that
just happens on its own.
It re-runs the prompt, which can take quite a while (depending on the
configuration), and which is also useless in this context as this
isn't something the prompt will be reacting to (theoretically it
could, but I doubt the utility of displaying "PASTE" for a few milliseconds).
The topic monitor allows a client to wait for multiple events, e.g. sigchld
or an internal process exit. Prior to this change a client had to specify
the list of generations and the list of topics they are interested in.
Simplify this to just the list of generations, with a max-value generation
meaning the topic is not interesting.
Also remove the use of enum_set and enum_array, it was too complex for what
it offered.
The external-commands-only completion was briefly added in 3.1.0 and removed
in 3.1.1 (see #6798), which means we can remove some dead code.
Maybe we should just remove __fish_complete_external_command - it could break
users, but then again, we don't really have a way to stop people from starting
to use this deprecated function. The underscores ought to communicate that
this is function is private to fish but that is not enforced.
It's not entirely clear why the existing check does not work, but it seems to pass on clang++ even without -latomic, but causes the fish build to fail later.
Confirmed that with this change, g++ does not use -latomic, while clang++ does, and fish builds fine with both.
This can be used to determine whether the previous command produced a real status, or just carried over the status from the command before it. Backgrounded commands and variable assignments will not increment status_generation, all other commands will.
This pulls in widechar_width.h from commit 7e9dfdaf05059b3f. The big change
here is that some characters which were previously marked as widened in 9
are now marked as unconditionally narrow; this includes some randoms like
hot pepper (U+1F336) but more importantly all of the regional indicators,
which affects how flags are rendered.
If you put two regional indicators together, you get a flag emoji. It's
unclear what the width of this flag emoji should be; Terminal and iTerm2
renders it as width 1, while kitty renders it as width 2. This is
unaffected by fish_emoji_width because the flag does not have an assigned
codepoint, it is a pair of codepoints.
The regional indicators are marked as "neutral" in EastAsianWidth.txt which
means they conceptually have width 1. So two of them have width 2. So now
we assume that flags are rendered as width 2.
This fixes#7237, for terminals that render flags as width 2 (but not 1,
unfortunately, which includes iTerm2 and Terminal.app).
This pulls in widechar_width.h from commit d4e75d5bb1930291223d1.
This is a "rebuild with latest data" before we attempt a risky bugfix.
The idea here is that bisecting can separate whether any regression is
due to using the latest Unicode data, or the bug fix.
