Taking a different approach here. I can't see why we'd only want to
recognize certain colors. Now, we'll just try all the colors fish might
use.
This could probably be optimized now that there are more
than 8 (or 16) colors fish can do.
My previous change to avoid creating a *.pyc file when running
create_manpage_completions.py was wrong because I put the
`sys.dont_write_bytecode = True` on the wrong line. Rather than simply
move that statement make the simpler, cleaner, fix that removes the need
for `eval` where that program is invoked.
The Linux kernel only splits on the first whitespace in the shebang line
(unlike BSD which splits on all whitespace). Which means there can be
only one argument after the path to the program.
Producing man pages is done infrequently (basically just at `make test`
and `make install`) so there isn't any point in writing compiled
byte-code versions of the python modules.
This change causes our configure script to just use the default behavior
of autoconf: in practice it will try g++ instead of clang++ first.
There are good reasons to use the behavior this reverts, namely g++
might be a symlink to clang++ and clang++ is never a symlink to g++ -
when `configure` says using "g++" that doens't tell us much.
On more systems than not, as far as I can tell, clang++ will often be a
newer compiler than g++ from what I can see as well.
However, it appears we have some bad things happening with Cygwin on
clang.
Fixes#3435
It is believed there are no longer any platforms we support that do not
support passing NULL as the second argument to realpath(). So rather
than duplicating the logic to get reasonable behavior from our
wrealpath() wrapper simply remove the redundant implementation.
After implementing `builtin fish_realpath` it was noticed that it did
not behave like GNU `realpath` without options. Which is super annoying
since that was the whole point of implementing the command. Major
failure on my part since I wrote the unit tests to match the behavior of
the existing `wrealpath()` function that I simply exposed as a builtin
command. Rather than actually verifying it behaved in a manner
compatible with GNU realpath.
Also, while the decision to call the builtin `fish_realpath` seemed to
make sense at the time of the original commit further reflection has
shown that to be a silly, idiosyncratic, thing to have done. So rename
it to simply `realpath`.
Fixes 3400
For now don't restyle all the fish scripts. That's because there
are still problems with the `fish_indent` output that require manual
intervention. Not to mention that very few of the fish scripts even
conform to `fish_indent` output at this time.
It's the ninth color - on virtual consoles this was likely to
try a color that doesn't work because we checked if max_colors >= 8.
Add another way to reach that color on terminals with only 8 colors
by using bold mode to get a bright.
This has potential to fail by simply rendering as black which can cause
it to be invisible on a white-on-black terminal. Not bad as it's just
making this bell/whistle invisible:
We *really* want to set the omitted newline character apart by having
it appear grey. On (FreeBSD consoles, at least) VCs it's not uncommon
for it to render as a "?". It's particularly confusing if it doesn't
render in a darker color as it cannot be discerned from actual program
output.
When performing fuzzy completion, if a directory segment is
valid, then don't consider it for a fuzzy match even if
the literal match produces no results.
Fixes#3211
The use of wcstoimax causes certain out-of-range values
to be silently truncated (e.g. when converted to a pid),
and is incompatible with FreeBSD (see #626)
This reverts commit 6faa2f9866.
The template has different behavior around interpreting
non-decimal sequences. This doesn't seem to have been intended.
This reverts commit f843eb3d31.
Both GNU and BSD have bugs regarding the classification of
non-characters and private use area characters. Provide wrappers around
iswalnum(), iswalpha(), and isgraph() to provide a consistent
experience. We don't bother to autoconf the use of these wrappers for
several reasons. Including the fact that a binary built for one distro
release should behave correctly on another release (e.g., FreeBSD 10
does the right thing while FreeBSD 11 and 12 do not with respect to
iswalnum() of code points in the range 0xFDD0..0xFDFF).
Also move a few functions from common.* to wutil.* because they are wide
char specific and really belong in the latter module.
Fixes#3050
