* Fix manpath handling in create_manpage_completions.py
...as well as do some (very!) light cleanup.
Currently, `create_manpage_completions.py` does not properly
understand/respect the `$MANPATH` variable. One important feature of
`$MANPATH` is that an empty component (i.e. the trailing : in
`foo:bar:`) expands to the 'default' or 'system' path -- that is to say,
the path that would be used if `$MANPATH` was unset. This allows the
user to extend the manpath without clobbering it, and has been a feature
many Unices have included for years.
The current implementation blindly uses the `$MANPATH` variable if it
exists, which does not allow for this behaviour -- to expand the
variable correctly, an external program must be invoked. Therefore, we
first shell out to the 'proper' (read: best guess) external program. If
that fails, we can then try to use `$MANPATH` directly/literally.
Finally, if both of those are impossible, we can fall back to some
common paths from widely used operating systems.
Note that the `man.conf` parsing has been removed: this is because while
many 'traditional' Unices (BSDs, Solaris, macOS) support this file, only
macOS actually ships a file -- most other Unices use a `conf.d`-style
layout and supporting that from our Python is impractical and silly at
best. On GNU (read: Linux) systems, `mandb` uses `/etc/man_db.conf` with
slightly different syntax and sematics. As this code-path has bitrotted
(and likely never worked, anyway), just remove it.
`create_manpage_completions.py` looks like it has suffered a lot of
confusion and bitrot in general over the last few years -- and is
overdue for a major refactoring. I am quite interested in tackling this,
but I plan to wait until the go-ahead to drop support for Python 2 is
given, as a major refactor/rewrite that still supports Python 2 (and
thus ignores the ergonomic/API/syntax improvements of Python 3) does not
make sense to me.
Related: #5657
It would probably be good to revisit `man.fish` once again when a
comprehensive refactor happens: hopefully every permutation of
`man`/`$MANPATH` could be documented as part of that effort.
* Restore /etc/man.conf parsing
I was not aware that this codepath was used -- since it appeared that it
would throw an error when it was reached. Redo it, using regex, and
support parsing NetBSD man.conf as well (untested).
* Fix create_manpage_completions.py under Python 2
I kinda hate how fussy clang-format is. It reflows text
constantly (line limit), forces things onto one line *except* when
they're too long, and wants to turn this:
```c++
return true;;
```
into this:
```c++
return true;
;
```
instead of, you know, eliminating the second semicolon?
Anyway, it is what it is and we use it, I'll just look into getting some
more slack.
The default indicator ruined alignment, which is a major design
feature here.
Handle it by including the mode indicator in the prompt proper.
Fixes#6802.
[ci skip]
Mostly line breaks, one instance of tabs!
For some reason clang-format insists on two spaces before a same-line comment?
(I continue to be unimpressed with super-strict line length limits,
but I continue to believe in automatic styling, so it is what it is)
[ci skip]
6902459566 was an attempt to not print
$status twice in the prompt. As a result we print $pipestatus but
not $status, which /usually/ is the same as $pipestatus[-1] --- unless
the builtin "not" is used, which inverts the $status of a job (it does
not alter $pipestatus).
As a result, the default prompt prints unexpected status codes:
~ > not false
~ [1]> not true
~ > not true | true
~ > not false | false
~ [1|1]>
This commit reintroduces printing of $status after $pipestatus, but only
if it is different from $pipestatus[-1].
Additionally, we only print anything at all if the $status is nonzero,
to avoid confusing output on `not false | false`
~ > not false
~ > not true
~ [0] 1> not true | true
~ [0|0] 1> not false | false
~ >
I think this is closer to users' expectations for those cases; they should
not have to think about this implementation detail of the not-statement.
OpenBSD uses [unveil(2)](https://man.openbsd.org/unveil) in chromium and
firefox. This means that things outside of directories like ~/Downloads or /tmp are not visible to the
browsers.
Change webconfig so it uses tempfile.NamedTemporaryFile to create our temp file.
It's now good enough to do so.
We don't allow grid-alignment:
```fish
complete -c foo -s b -l barnanana -a '(something)'
complete -c foo -s z -a '(something)'
```
becomes
```fish
complete -c foo -s b -l barnanana -a '(something)'
complete -c foo -s z -a '(something)'
```
It's just more trouble than it is worth.
The one part I'd change:
We align and/or'd parts of an if-condition with the in-block code:
```fish
if true
and false
dosomething
end
```
becomes
```fish
if true
and false
dosomething
end
```
but it's not used terribly much and if we ever fix it we can just
reindent.
This removes a call to `sed` and allows the user to specify shortening
via the variable.
We still default to disabling shortening because this prompt never
did.
[ci skip]
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 was mostly dead, since $fish_color_host is set to normal in
__fish_config_interactive. The assignment was only used if the user
explicitly unsets fish_color_host (which they shouldn't, really).
Anyway it's weird to use cyan, use normal instead.
[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]
If a command fails, print the pipestatus in red instead of yellow and
don't print the status of the last process again. See #6375.
Also use $fish_color_status for coloring status consistently.
Also use __fish_pipestatus_with_signal to print SIGPIPE instead
of a numeric code on e.g.: yes | less +q
[ci skip]
- Don't use a guard uvar - we're only setting variables now, and
- that's basically free.
- Allow non-universal color variables
- Simplify the root color setting a bit.
- Some comments
[ci skip]
This mostly fixes some wrong indents or replaces some stray tab indents.
I excluded alignment on purpose, because we have a whole bunch of code
that goes like
```fish
complete -c foo -n 'some-condition' -l someoption
complete -c foo -n 'some-longer-condition' -l someotheroption
```
and changing it seems like a larger thing and would include more
thrashing.
See #3622.
Changes identity `is` for equality `==` check. To remove python warnings when updating auto complete
```
/usr/local/Cellar/fish/3.0.2/share/fish/tools/deroff.py:770: SyntaxWarning: "is" with a literal. Did you mean "=="?
if len(comps) is 2:
/usr/local/Cellar/fish/3.0.2/share/fish/tools/deroff.py:954: SyntaxWarning: "is" with a literal. Did you mean "=="?
if len(comps) is 2:
Parsing man pages and writing completions to /Users/james/.local/share/fish/generated_completions/
6155 / 6155 : zic.8
```
Since the url is inside a AngularJS markup {{url}}, it's better to use **ng-href**.
From [AngularJS Documentation](https://docs.angularjs.org/api/ng/directive/ngHref):
<br>
"Using AngularJS markup like {{hash}} in an href attribute will make the link go to the wrong URL if the user clicks it before AngularJS has a chance to replace the {{hash}} markup with its value. Until AngularJS replaces the markup the link will be broken and will most likely return a 404 error. The ngHref directive solves this problem."
This runs build_tools/style.fish, which runs clang-format on C++, fish_indent on fish and (new) black on python.
If anything is wrong with the formatting, we should fix the tools, but automated formatting is worth it.
No longer uses global vars to cache set_color output, this was
from before set_color was a builtin, it is pointless now.
This is also a prompt from before we had bright named colors,
and it appears it was relying on -o red to get bright red.
so use brred, etc.
