* added completions for sad and added note in changelog
* ran fish_indent on completion file
* split -h and --help into two distinct completion options
A recenty commit was loathe to assume the unicode ellipsis character
was safe so just used '..' instead. However I noticed we actually
already do use that character elsehwere in the completions.
So, just make both spots try to somewhat carefully use it.
We do this same `string match` check on LANG in fish_job_summary.fish
When adding a VLAN-enabled interface, it is named like enp0s31f6.100@enp0s31f6
with the physical interface being appended behind an @.
But subsequent ip commands operate on the interface name without this suffix,
so it needs to be removed when completing interface names in __fish_ip_device
These should be friendlier, but aren't as pedantically accurate.
I think the term "index" is terrible and much prefer "staging area".
Also "rev-parse" simply must be believed to be seen, it can't be
described in a single paragraph. (did you know you can use `git
rev-parse --parseopt` as a replacement for `getopt` in arbitrary
shell scripts?)
I have an alias called "lg" for
log --color --graph --pretty=format:\'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset\' --abbrev-commit --first-parent
Having that in my completions ensures that git commands essentially
always use one column at most. That's not great, so we now shorten it
to 35 chars (plus an annoying 2 for ".." because I can't be bothered
to check for unicode support - an argument for a "string ellipsize", I guess?)
"git add ./" shows only hidden files (if at all). It should show all files
that can be added.
The problem is that candidates come from "git status" which prints clean
relative paths. Let's allow some unclean paths.
This is far from a complete fix but it should work for the common scenario.
Observe that wildcard_complete_internal() actually filters out all non-hidden
files, if the query is `./`.
Closes#9091
This can be used to print the modification time, like `stat` with some
options.
The reason is that `stat` has caused us a number of portability
headaches:
1. It's not available everywhere by default
2. The versions are quite different
For instance, with GNU stat it's `stat -c '%Y'`, with macOS it's `stat
-f %m`.
So now checking a cache file can be done just with builtins.
- Generally better descriptions,
- uname checks to not complerte unavailable options on
NetBSD, FreeBSD, DragonFly, Solaris, Darwin
- Describe/complete GNU's --time=access,mtime... arg
- Remove -f it is a no-op and not documented.
This is sort of slow because it's called hundreds of times.
We used to have a cache, introduced in ad9b4290e, but it was removed
in fee5a9125a because it had
false-positives.
So what we do, because the issue is that this is called hundreds of
times per-commandline, we cache it keyed on the commandline.
This speeds up `complete -C'git sta'` by a factor of 2.3x.
Commit ad9b4290e optimized git completions by adding a completion that would
run on every completion request, which allows to precompute data used by
other completion entries. Unfortunately, the completion entry is not run
when the commandline contains a flag like `git -C`. If we didn't
already load git.fish, we'd error. Additionally, we got false positive
completions for `git diff -c`.
So this hack was a very bad idea. We should optimize in another way.
