The commit began passing the length of the wide string rather than the
length of the narrowed string after conversion via `wcstombs`. We *do*
have the actual length, but it's not (necessarily) the same as the
original value. We need to pass the result of `wcstombs` instead.
Mostly related to usage _(L"foo"), keeping in mind the _
macro does a wcstring().c_str() already.
And a smattering of other trivial micro-optimizations certain
to not help tangibly.
This tried to skip conversion if the locale had MB_CUR_MAX == 1, but
in doing so it just entered an infinite recursion (because
writestr(wchar_t*) called writestr(wchar_t*)).
Instead, just let wcstombs handle it.
Fixes#5724.
This helps on netbsd, because enter_standout_mode et al are const
there.
These methods don't alter their argument, so they should have been
const to begin with.
This is non-const on macOS, but some of the args we pass are always
const on netbsd.
I have no idea why you'd ever want this to modify its argument, but whatever.
While supported by gcc and clang, \e is a gcc-specific extension and not
formally defined in the C or C++ standards.
See [0] for a list of valid escapes.
[0]: https://stackoverflow.com/a/10220539/17027
On systems where the terminfo for TERM does not contain a string for
attributes such as enter_underline_mode, etc. fish was crashing with a
fatal error message and a note to email the developers.
These are non-essential text attribute changes and should not trigger
such a failure.
There were several issues with the way that the include tests for curses.h
were being done that were ultimately causing fish to use the headers from
ncurses but link against curses on platforms that provide an actual
libcurses.so that isn't just a symlink to libncurses.so
In particular, the old code was first testing for curses's cureses.h and then
falling back to libncurses's implementation of the same - but that logic was
reversed when it came to including term.h, in which case it was testing for
the ncurses term.h and falling back to the curses.h header. Long story short,
while cmake will link against libcurses.so if both libcurses.so and
libncurses.so are present (unless CURSES_NEED_NCURSES evaluates to TRUE, but
that makes ncurses a hard requirement), but we were brining in some of the
defines from the ncurses headers, causing SIGSEGV panics when fish ultimately
tried to access variables that weren't exported or were mapped to undefined
areas of memory in the other library.
Additionally it is an error to include termios.h prior to including the plain
Jane curses.h (not ncurses/curses.h), causing errors about unimplemented types
SGTTY/chtype. So far as I can tell, both curses.h and ncurses/curses.h pull in
termios.h themselves so it shouldn't even be necessary to manually include it,
but I have just moved its #include below that of curses.h
This eliminates the "missing" notion of env_var_t. Instead
env_get returns a maybe_t<env_var_t>, which forces callers to
handle the possibility that the variable is missing.
Internally fish should store vars as a vector of elements. The current
flat string representation is a holdover from when the code was written
in C.
Fixes#4200
This is the first step to implementing issue #4200 is to stop subclassing
env_var_t from wcstring. Not too surprisingly doing this identified
several places that were incorrectly treating env_var_t and wcstring as
interchangeable types. I'm not talking about those places that passed
an env_var_t instance to a function that takes a wcstring. I'm talking
about doing things like assigning the former to the latter type, relying
on the implicit conversion, and thus losing information.
We also rename `env_get_string()` to `env_get()` for symmetry with
`env_set()` and to make it clear the function does not return a string.
There should be just one place that calls `setupterm()`. While refactoring
the code I also decided to not make initializing the curses subsystem a
fatal error. We now try two fallback terminal names ("ansi" and "dumb")
and if those can't be used we still end up with a usable shell.
Fixes#3850
I recently upgraded the software on my macOS server and was dismayed to
see that cppcheck reported a huge number of format string errors due to
mismatches between the format string and its arguments from calls to
`assert()`. It turns out they are due to the macOS header using `%lu`
for the line number which is obviously wrong since it is using the C
preprocessor `__LINE__` symbol which evaluates to a signed int.
I also noticed that the macOS implementation writes to stdout, rather
than stderr. It also uses `printf()` which can be a problem on some
platforms if the stream is already in wide mode which is the normal case
for fish.
So implement our own `assert()` implementation. This also eliminates
double-negative warnings that we get from some of our calls to
`assert()` on some platforms by oclint.
Also reimplement the `DIE()` macro in terms of our internal
implementation.
Rewrite `assert(0 && msg)` statements to `DIE(msg)` for clarity and to
eliminate oclint warnings about constant expressions.
Fixes#3276, albeit not in the fashion I originally envisioned.
We should never use stdio functions that use stdout implicitly. Saving a
few characters isn't worth the inconsistency. Too, using the forms such
as `fwprintf()` which take an explicit stream makes it easier to find
the places we write to stdout versus stderr.
Fixes#3728
* Add italics and dim modifier to set_color
* update documentation for set_color
* add reverse mode to set_color
* Use standout mode as fallback for reverse mode
* Apply patch from @Darkshadow2 adding additional modes
Using `\e` is clearer and shorter than `\x1b`. It's also consistent with how
we write related control chars; e.g., we don't write `\x0a` we write '\n'.
There are several places that use writestr() which should instead be
using fwprintf() or equivalent. Also, clarify the documentation for why
writestr() and writechr() exist so they aren't used inappropriately
again.
Fixes#3657
Earlier lint cleanups overlooked a couple of modules because on macOS at
the moment oclint ignores them. I noticed this when I ran `make lint-all`
on Ubuntu.
Fish assumed that it could use tparm to emit escapes to set colors
as long as the color was under 16 or max_colors from terminfo was 256::
if (idx < 16 || term256_support_is_native()) {
// Use tparm to emit color escape
writembs(tparm(todo, idx);
If a terminal has max_colors = 8, here is what happenened, except
inside fish:
> env TERM=xterm tput setaf 7 | xxd
00000000: 1b5b 3337 6d .[37m
> env TERM=xterm tput setaf 9 | xxd
00000000: 1b5b 3338 6d .[39m
The first escape is good, that second escape is not valid.
Bright colors should start at \e[90m:
> env TERM=xterm-16color tput setaf 9 | xxd
00000000: 1b5b 3931 6d .[91m
This is what caused "white" not to work in #3176 in Terminal.app, and
obviously isn't good for real low-color terminals either.
So we replace the term256_support_is_native(), which just checked if
max_colors is 256 or not, with a function that takes an argument and
checks terminfo for that to see if tparm can handle it. We only use this
test, because otherwise, tparm should be expected to output garbage:
/// Returns true if we think tparm can handle outputting a color index
static bool term_supports_color_natively(unsigned int c) { return max_colors >= c; }
...
if (term_supports_color_natively(idx) {
And if terminfo can't do it, the "forced" escapes no longer use the fancy
format when handling colors under 16, as this is not going to be compatible with
low color terminals. The code before used:
else {
char buff[16] = "";
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
I added an intermediate format for colors 0-15:
else {
// We are attempting to bypass the term here. Generate the ANSI escape sequence ourself.
char buff[16] = "";
if (idx < 16) {
snprintf(buff, sizeof buff, "\x1b[%dm", ((idx > 7) ? 82 : 30) + idx + !is_fg * 10);
} else {
snprintf(buff, sizeof buff, "\x1b[%d;5;%dm", is_fg ? 38 : 48, idx);
}
Restores harmony to white, brwhite, brblack, black color names.
We don't want "white" to refer to color color #16, but to the
standard color #8. #16 is "brwhite".
Move comments from output.h to output.cpp
Nuke the config.fish set_color hack for linux VTs.
Sync up our various incomplete color lists and fix all color values.
Colors 0-8 are assumed to be brights - e.g. red was FF0000. Perplexing!
Using this table:
<http://www.calmar.ws/vim/256-xterm-24bit-rgb-color-chart.html>
Fixes#3176
We were effectively inferring 256 color support **only**.
If terminfo reports 256 max_colors for this $TERM but
that is not named xterm or does not contain "256color" in name,
term256_support_is_native()'s result did not affect the recorded
support.
Noticed with Terminal.app set to nsterm, and a newer ncurses
with good terminfo for the terminal on modern OS X:
http://invisible-island.net/ncurses/terminfo.src.html#toc-_Apple__Terminal_app
