Rewrite completions for meson to expose meson commands with their
options and subcommands. New completions are based on the meson 1.0.
Subcommands were introduced in meson 0.42.0 (August 2017), so new
completions will only work for versions after 0.42.0. At this moment,
even oldstable Debian (buster) has meson 0.49.2 -- which means it is
unlikely someone will be affected.
---------
Co-authored-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
By default, fish does not complete files that have leading dots, unless the
wildcard itself has a leading dot. However this also affected completions;
for example `git add` would not offer `.gitlab-ci.yml` because it has a
leading dot.
Relax this for custom completions. Default file expansion still
suppresses leading dots, but now custom completions can create
leading-dot completions and they will be offered.
Fixes#3707.
When we draw the prompt, we move the cursor to the actual
position *we* think it is by issuing a carriage return (via
`move(0,0)`), and then going forward until we hit the spot.
This helps when the terminal and fish disagree on the width of the
prompt, because we are now definitely in the correct place, so we can
only overwrite a bit of the prompt (if it renders longer than we
expected) or leave space after the prompt. Both of these are benign in
comparison to staircase effects we would otherwise get.
Unfortunately, midnight commander ("mc") tries to extract the last
line of the prompt, and does so in a way that is overly naive - it
resets everything to 0 when it sees a `\r`, and doesn't account for
cursor movement. In effect it's playing a terminal, but not committing
to the bit.
Since this has been an open request in mc for quite a while, we hack
around it, by checking the $MC_SID environment variable.
If we see it, we skip the clearing. We end up most likely doing
relative movement from where we think we are, and in most cases it
should be *fine*.
This removes a possibility of an infinite loop where something in
__fish_config_interactive triggers a fish_prompt or fish_read event,
which calls __fish_on_interactive which calls
__fish_config_interactive again, ...
Fixes#9564
This wanted to get the default priority, and it ran a thing *at source
time*.
This can lead to a variety of errors and I don't believe it's all that
useful, so we remove it.
This is an additional tool, and this function is executed on source
time so we'd spew errors.
(also remove an ineffective line - it's probably *nicer* with the
read, but that's not what's currently effectively doing anything)
We should fix this warning eventually. Silence it for now to make Clippy
pass without warnings, which makes it much more useful.
Compiling fish-rust v0.1.0 (/home/johannes/git/fish-riir/fish-rust)
error: mutable borrow from immutable input(s)
--> src/ffi.rs:79:32
|
79 | pub fn get_procs(&self) -> &mut [UniquePtr<process_t>] {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: immutable borrow here
--> src/ffi.rs:79:22
|
79 | pub fn get_procs(&self) -> &mut [UniquePtr<process_t>] {
| ^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#mut_from_ref
= note: `#[deny(clippy::mut_from_ref)]` on by default
error: could not compile `fish-rust` due to previous error
A following commit will pass global string constants to the gettext macro.
This is not ideal because we might accidentally use the constants without
gettext (which we should never do). To fix that we might need to define a
macro per constant, or use a proc macro which is maybe not worth it.
warning: deref which would be done by auto-deref
--> src/wchar_ffi.rs:81:5
|
81 | &*EMPTY_WSTRING
| ^^^^^^^^^^^^^^^ help: try this: `&EMPTY_WSTRING`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#explicit_auto_deref
= note: `#[warn(clippy::explicit_auto_deref)]` on by default
Separate the neovim completions from the vim ones, as their supported
options have diverged considerably.
Some documented options are not yet implemented, these are added but
commented out.
Closes#9535.
---------
Co-authored-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
This is an easy win for `git add ` completion time if we have multiple descriptions.
What happened was we did things once per description string, but the
things included a bunch of computation (including multiple `string`
calls and even a `realpath`!). Because these don't change, we can
simply do them once.
And it turns out we can just use a cartesian product:
for d in $desc
printf '%s\t%s\n' $file $d
end
becomes
printf '%s\n' $file\t$desc
lazy_static has better ergonomics at the call/access sites (it returns a
reference to the type directly, whereas with once_cell we get a static Lazy<T>
that we must dereference instead) but the once_cell api is slated for
integration into the standard library [0] and has been the "preferred" way to
declare static global variables w/ deferred initialization. It's also less
opaque and easier to comprehend how it works, I guess?
(Both `once_cell` and `lazy_static` are already in our dependency tree, so this
should have no detrimental effect on build times. It actually negligibly
*improves* build times by not using macros, reducing the amount of expansion the
compiler has to do by a miniscule amount.)
[0]: https://github.com/rust-lang/rust/issues/74465
I have no idea why `apt-cache --no-generate show` is so slow since it basically
dumps the contents of the cache file located at `/var/lib/dpkg/status`. We are
technically bypassing any waits on the cache lock file so this may produce
incorrect results if the cache is being regenerated in the moment, but that's a
small price to pay and the results are likely confined to simply not generating
comprehensive results.
With this change, we no longer need to truncate results to the first n matches
and we no longer only print packages beginning with the commandline argument
enabling fish's partial completions logic to offer less-perfect suggestions when
no better options are available.
Even though we are generating more usable completions, we still trounce the old
performance by leaps and bounds:
```
Benchmark #1: fish -c "complete -C\"apt install ac\""
Time (mean ± σ): 2.165 s ± 0.033 s [User: 267.0 ms, System: 1932.2 ms]
Range (min … max): 2.136 s … 2.256 s 10 runs
Benchmark #2: build/fish -c "complete -C\"apt install ac\""
Time (mean ± σ): 111.1 ms ± 1.8 ms [User: 38.9 ms, System: 72.9 ms]
Range (min … max): 108.2 ms … 114.9 ms 26 runs
Summary
'build/fish -c "complete -C\"apt install ac\""' ran
19.49 ± 0.44 times faster than 'fish -c "complete -C\"apt install ac\""'
```
I think this should be preferred for all subcommand completions because it
handles typos or subcommands we don't recognize better (`apt foo <TAB>` no
longer suggests subcommands since the subcommand position has been taken).
It's debatable whether is_ascii_digit() is better than (0..=9).contains().
(Probably we want to go with the mainstream Rust choice eventually.)
Let's disable the warning for now since it's not terribly important.
We should only be dealing with wcharz_t at the language boundary.
Rust callers should prefer the equivalent &wstr.
Since wcsfilecmp() is no longer exposed directly it can take &wstr only.
- Added phx completions. These are very common completions for the Elixir Phoenix Framework.
Documentation can be found here: https://hexdocs.pm/phoenix/1.7.0-rc.2/Mix.Tasks.Local.Phx.html#content
- Added argument completions
- Made all descriptions start with an uppercase for better consistency
- Update CHANGELOG.rst
