This is early work but I guess there's no harm in pushing it?
Some thoughts on the conventions:
Types that live only inside Rust follow Rust naming convention
("FeatureMetadata").
Types that live on both sides of the language boundary follow the existing
naming ("feature_flag_t").
The alternative is to define a type alias ("using feature_flag_t =
rust::FeatureFlag") but that doesn't seem to be supported in "[cxx::bridge]"
blocks. We could put it in a header ("future_feature_flags.h").
"feature_metadata_t" is a variant of "FeatureMetadata" that can cross
the language boundary. This has the advantage that we can avoid tainting
"FeatureMetadata" with "CxxString" and such. This is an experimental approach,
probably not what we should do in general.
The initial port of feature flags requires a global initialization. Since
fish_indent accesses feature flags, let's make sure to initialize them here.
In future, we can stop initializing things fish_indent doesn't need (like
the topic monitor) but that's no big deal. Global initialization should
always be a benign addition.
The original implementation without the test took me 3 hours (first time
seriously looking into this)
The functions take "wcharz_t" for smooth integration with existing C++ callers.
This is at the expense of Rust callers, which would prefer "&wstr". Would be
nice to declare a function parameter that accepts both but I don't think
that really works since "wcharz_t" drops the lifetime annotation.
rustfmt removes the "::" prefix from qualifiers. This breaks the build because
I think a later "pub use ffi::*" results in "std" being an ambiguous reference.
We can re-enable these once we're nearing a RIIR release (or if someone thinks
it's a good use of their time to fix them before then). Otherwise we're just
going to have GitHub reporting CI failure for all commits instead of just the
ones that actually broke something.
(I'm mainly trying to get the branch in a good state to merge into master.)
Use rustup to install the latest version of rust. The latest version of rust
available from pkg is 1.66.0 while the code currently needs 1.67.0 or later.
The nix crate had all its default features enabled, which included features that
are not present under BSD. We should only enable the select subset of crate
features that we know are available cross-platform (or else use conditional
targeting in Cargo.toml to only enable Linux-only features when compiling for
Linux targets).
For now, it seems we can just use the nix crate with all features disabled as it
still builds under Linux and FreeBSD in this state.
The `cmake` meta package pulls in `cmake-core`, `cmake-docs`, and `cmake-man` -
we don't need the latter two.
(It seems to be available on all the versions/architectures we target.)
The git-lite flavor, being significantly smaller and downloading/installing much
faster with fewer dependencies, is much better suited for CI environments (at
the cost of not supporting interactive git commands).
By default /etc/pkg/FreeBSD.conf uses either the /quarterly or /latest pkg
builds, which are built against the latest minor release of FreeBSD for the
given ${ABI} string at the time they were last updated.
The nature of the shared binary packages means everyone (across all minor
versions of the same major version on the same architecture, all of which share
the same stable ABI) gets the same binary build.
There are however packages which depend on symbols exported by system-provided
libraries (rather than by other packages, which are always going to be in sync)
that *aren't* stable across minor releases, leaving packages like llvm
broken if you install the latest llvm from pkg's binary repos built against,
say, FreeBSD 13.1 while running FreeBSD 13.0.
The other option is to use the "snapshots" of the binary packages available upon
the release of each minor version, by using /release_0, /release_1, etc instead
of /quarterly or /latest, but then you're limited to the ports that were
available at that specific date and those old versions.
tl;dr just make sure we're always using the latest minor release for each major
version of FreeBSD we intend to support.
This works around an autocxx limitations where different types cannot
have the same name even if they live in different namespace.
ast::job_t conflicts with job_t.
This adds an implementation of fish_wcstoi in Rust, mirroring the one in
fish. As Rust does not have a string to number which infers the radix
(i.e. looks for leading 0x or 0), we add that manually.
In v3 several input parameters where renamed and since v4 it requires Node.js 16.
This resolves warnings about Node.js 12 and `set-output` being deprecated and
slated for removal in the `Lock threads` workflow.
This addresses the node v12 deprecation warning in the GitHub CI, caused by the
dependency on actions/checkout@v2.
While actions/checkout@v3 introduces some new features and changes some
defaults, the subset of features that we use should not be affected by this
migration.
The "breaking change" from v2 to v3 can be seen at [0]. Since we are tracking
only v2 without a dot release specified, we are already opting into any breakage
across minor versions, so really the only change of note is the node version
upgrade.
[0]: https://github.com/actions/checkout/compare/v2.4.2...v3.0.0
This translated ctrl-k to "\v", which is a "vertical tab", and ctrl-l
to "\f" and ctrl-g to "\a".
There is no "vertical tab" or "alarm" or "\f" *key*, so these
shouldn't be translated. Just drop these and call them `\ck` and such.
(vertical tab specifically is utterly useless and I would be okay with
dropping it entirely, I have never seen it used anywhere)
That commit did way too many things, making it hard to see the 5 regressions
it introduced. Let's revert it and its stragglers. In future, we could redo
some of the changes.
Reverts changes to share/completions/git.fish from
- 3548aae55 (completions/git: Don't leak submodule subcommands, 2023-01-23)
- 905f788b3 (completions/git: Remove awkward newline symbol, 2023-01-10)
- 2da1a4ae7 (completions/git: Fix git-foo commands, 2023-01-09)
- e9bf8b9a4 (Run fish_indent on share/completions/*.fish, 2022-12-08)
- d31847b1d (Fix apparent dyslexia, 2022-11-12)
- 054d0ac0e (git completions: undo mistaken `set -f` usage, 2022-10-28)
- f5711ad5e (git.fish: collapse repeat complete cmds, set -f, rm unneeded funcs, 2022-10-27)
Bracketed paste adds one undo entry unless the pasted text contains a '
or \. This is because the "paste" bind-mode has bindings for those keys,
so they effectively start a new undo entry.
Let's fix this by adding an explicit undo group (our first use of this
feature!).
As pointed out by faho, the completions will be deduplicated by the completion
mechanics. We don't use this list directly except to pass it up the chain to the
shell, so there's no benefit to shelling out to eagerly deduplicate the list.
Plus, as of 3.6.0, even manual `complete -C"..."` invocations now deduplicate
results the same as if completions were triggered.
`fail2ban-client` uses nested subcommand syntax and intermixes fixed/enumerable
values with dynamically detected ones. If you know exactly what your overall
command structure looks like, these completions will work great. Unfortunately
their discoverability is a bit lacking, but that's not really fish's fault.
e.g.
* `f2b-c get/set` take certain known values but also accepts a dynamic jail name
* `f2b-c get/set <jail>` take certain fixed options but...
* `f2b-c get/set <jail> action` require enumerating an entirely different set
of values to generate the list of completions, bringing us to...
* `f2b-c get <jail> action <action>` has a fixed number of options but
* `f2b-c set <jail> action <action> <property>` can be any valid command and its
arguments
The intermixing of fixed, enumerable, and free-form inputs in a single command
line is enough to make one's head spin!
