fish 2.5 beta raises the C++ toolchain requirement
fish 2.5b1 requires C++11 and stops publishing some older Linux packages. The same beta introduces an explicit hybrid binding preset built from Emacs and Vi configurations.
A shell's compatibility includes the machines on which its binary can run, as well as the command language it accepts. fish 2.5b1 raises its C++ requirement to C++11. On older systems, obtaining a new fish release can now require a different compiler or standard library even when the user's interactive configuration is unchanged.
The January 14 beta notes describe the affected platforms explicitly. They also introduce hybrid key bindings and revised behavior when exiting with background processes. The release is a beta, so these are changes available for evaluation before the stable 2.5 release.
I value fish's interactive defaults, but a shell is also a program that must start in the environment where it is installed. The toolchain change deserves the same attention as a visible editing feature because it determines who can obtain and run the binary.
Source compatibility depends on the build toolchain
For Linux source builds, the notes identify GCC's g++ 4.8 or newer and LLVM's clang 3.3 or newer as known working compilers. Older systems may need a newer compiler installed. The requirement is for the language implementation used to build fish, not for users to write their shell configuration in C++.
The distribution consequence is narrower than dropping all support for old Linux systems. The fish developers stop publishing binary packages for specific platforms because of toolchain complexity. Building from source remains the stated route to installing a newer fish on those systems.
The listed platforms are Red Hat Enterprise Linux and CentOS 5 and 6 for 64-bit builds, Ubuntu 12.04 and Debian 7. That list should not be generalized into a claim that every older distribution or every architecture loses packages in precisely the same way. The release notes define the actual packaging scope.
This distinction matters for a machine maintained through distribution packages. A working older fish installation does not imply that the same package source will supply the new release. The upgrade now includes choosing how to obtain a compatible build.
A compiler and its runtime library are separate requirements
The OS X 10.6 case concerns a C++11 standard library. The notes identify a missing /usr/lib/libc++.1.dylib as the cause of a loader error when the library is absent. A binary can therefore be built successfully elsewhere yet fail to start on that machine.
The notes recommend obtaining the library through MacPorts for Snow Leopard. They say OS X 10.7 and later already include the required library. That separates a specific runtime dependency on 10.6 from the broader language requirement used during compilation.
A toolchain transition can consequently appear at different stages. A source builder can encounter compiler requirements, while a binary user can encounter loader requirements. Describing both as a generic installation failure would obscure which component needs to be supplied.
The release does not present this as a change to fish's scripting syntax. A shell function remains fish code. C++11 is an implementation dependency, with consequences for how the executable is built and linked.
Hybrid bindings become an explicit preset
The beta also adds fish_hybrid_key_bindings. The release notes describe it as combining Emacs-style and Vi-style bindings and resembling the Vi binding behavior from fish 2.3.0. This gives the combination its own name instead of requiring every user to construct it manually.
The function shipped in the beta shows how it combines the sets. It clears existing bindings, installs default bindings in the default, insert and visual modes, and then calls fish_vi_key_bindings --no-erase.
fish_hybrid_key_bindings
That function call selects the preset. Its implementation also updates fish_key_bindings, with handling to preserve the variable's existing scope when present. The code comments explain that the variable handler calls the function again and arranges for user key bindings to execute.
The order of installation explains the preset's behavior more accurately than calling it two simultaneous independent editors. Default bindings supply a base in each named mode, and the Vi setup adds its mode-aware definitions without erasing that base.
I prefer a named preset for this combination because it makes the choice visible in configuration. Users who want modal editing with familiar Emacs controls have an interface that states that preference directly.
Process handling also becomes more explicit
Exiting with running background processes now produces a warning. A second exit attempt signals those processes to terminate, bringing their treatment into line with stopped processes. This is an interactive behavior change, independent of the compiler transition.
The beta also adds status subcommands while retaining the old option forms. For example, the notes recommend status is-interactive. Only one subcommand or action option can be specified at a time.
These changes give users concrete interfaces to evaluate alongside the build requirements. A platform must first supply the compiler or runtime needed for fish to run. Once it does, the beta exposes explicit choices for editing presets and a clearer warning before an exit affects background work.