Recently Safari seems to hang with fish webconfig. This is apparently
because Safari is opening a socket and not writing to it, causing
webconfig to hang until the timeout (30 seconds). It's not clear why.
Use ThreadingMixIn so that FishConfigTCPServer can handle more
than one connection at a time. This fixes the hang under Safari.
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 prints a description of the "host". Currently that's
`(chroot:debianchroot) $USER@$hostname`
with the chroot part when needed.
This also switches the default and terlar prompts to use it, the other
prompts have slightly different coloring or logic here.
These were hard to read in the browser, but not in the terminal.
The palette in color.cpp lists #000080 for blue, which is *even darker*. I'm not sure if that's actually a thing - I was under the impression that table was taken from xterm.
Either way, listing it in this color doesn't do anyone any favors. It's just a rough approximation anyway.
Otherwise this has filesystem order, which on my system is quite
chaotic.
An alternative would be to randomize the order so people see different
prompts each time.
Some features:
- A nice `►` prompt char with a fallback for non-utf8 systems
- The $PWD is colored depending on its sha, so different directories
are colored differently, but each directory stays the same
- User@Host is only shown if not on the local machine (ssh or
virtualization)
- A right prompt with a nice git display, date, duration of the last
command (if it took over 100ms), and virtualenv
This gets fish to print the right prompt of any sample if it has any,
and then shows it separately.
If there is a right prompt, it will also save it. If not, it will *not* overwrite an existing right prompt.
This should be a simple prompt that doesn't place a huge strain on the
system but communicates the most important information simply and
effectively.
It should be a good jumping off point for making your own prompt.
Unless that person directly contributed the prompt.
We name them after a feature - the Scales prompt feature a ">>>" which
kinda looks like fish scales, the "Arrow" prompt starts with a
prominent "➜".
Naming them after people looks like an endorsement of that particular
person, and like they are someone to look up to, especially when they
aren't involved with the project.
The "terlar" and "acidhub" prompts stay for now because they
contributed the prompt themselves, they are also much less prominent.
The "classic" prompts are all just variations on a theme, let's just
keep the default classic+vcs.
"Justadollar" is very unlikely to be what you want and also trivial to
write yourself.
I have no idea what screen_savvy even is for - it reacts to "$WINDOW",
but I don't know anything that even uses that variable.
Lonetwin is just unremarkable, and the debian chroot prompt has one special feature that should be integrated into the other prompts.
When `fish` is running in the Chrome OS Linux VM (Crostini),
both `help` and `fish_config` opened a "file not found"
page. That is because on Crostini, `BROWSER` is usually set to
`garcon-url-handler`, which opens URLs in the host OS Chrome
browser. That browser lacks access to the Linux file system.
This commit fixes these commands. `help` now opens the URL on
www.fishshell.com. `fish_config` now opens the URL for the
server it starts. Previously, it opened a local file that
redirects to the same URL.
In the case of `help`, the situation could be improved further
by starting a web server to serve help. I don't know of another
way to access `/share/fish` from outside the VM without user
intervention, and I think that might be a part of the security
model for the Crostini VM.
It's hard to write a test for this. I checked that `help math`,
`python2 webconfig.py`, and `python3 webconfig.py` work on my
machine running in Crostini.
* Ensure web_config works on WSL
web_config could sometimes fail on WSL if the user chose not to append
windows directories to their linux $PATH. This change ensures that the
cmd.exe executable is found in most cases even if windows directories
are not appended to $PATH on linux.
An error message letting the user know that cmd.exe was not found, and
that they should add the cmd.exe dir to their $PATH before running
fish_config is displayed if cmd.exe is still not found.
* Exit with a non 0 status code if cmd.exe is not found
This still showed the background gradient, which is just a waste and
looks weird.
Instead make the actual content fullscreen (except for the border
radius, for now)
I ran into problems described in https://github.com/fish-shell/fish-shell/issues/718 when using this prompt. This seems to be a bug in the prompt -- this change fixes it, at least on my system.
I tried this in tmux (TERM=screen) and gnome-terminal (TERM=xterm-256) with fish 3.1.2, on Linux.
This had a classic float:left layout, which led to awkward gaps and
stuff.
Since what we want here is basically 100% exactly a flexbox, just use that.
Note: No flexbox for the prompts, atm, because having multiple of
those next to each other looks a bit weird.
Fix 1: The --quiet flag must be at the end of the command. The way it was I would never get any status symbol in my prompt as the command failed.
Fix 2: After adding files to git, but before committing them, git status is unsorted. This gave me the output "M A M A" after `uniq`, which resulted in 4 status symbols instead of 2. Sorting them before filtering them fixed the problem.
There's a macOS bug with Source Code Pro that makes it unable to be
colored. Since that makes webconfig unusable, stop recommending it.
Instead, we just pick the default monospace font for the system.
This is slated for removal in python 3.10, see
https://www.python.org/dev/peps/pep-0594/#cgi.
We currently only use it for three things:
- escape_html in old python versions that didn't have that in the html
module
- Parsing multipart/form-data
- Figuring out the charset for json
We keep the first one - if loading escape_html from html fails we fall
back to cgi.
We remove the second - I can't find any case where we use
multipart/form-data. Any place we post data we either explicitly pass
application/x-www-form-urlencoded or implicitly use application/json.
The third is the tricky bit. This drops charset detection under the
assumption that we're never going to encounter anything other than
utf-8 (or ascii, which is a utf-8 subset). I'm not sure that holds,
but if it doesn't we can just add a regex to parse the charset.
These used a different object format, so they were passed to
interpret_color wrong.
Because the "common" and "syntax" division doesn't really help all
that much, let's just flatten the thing.
See #7596.
And again clang-format does something I don't like:
- if (found != end && std::strncmp(found->name, name, len) == 0 && found->name[len] == 0) return found;
+ if (found != end && std::strncmp(found->name, name, len) == 0 && found->name[len] == 0)
+ return found;
I *know* this is a bit of a long line. I would still quite like having
no brace-less multi-line if *ever*. Either put the body on the same
line, or add braces.
Blergh
