本着总想折磨一下自己这个本源愿望，最近尝试了从 zsh 迁到 fish。

尽管 fish 有很多不错的功能（比 zsh 阳间许多的配置文件管理，条理清晰的变量控制 etc），但是事实上各个 shell 的生态并不完全相同。

我曾经使用 p10k + zinit，它很好，我很喜欢它。但是 p10k 已经打出了 「THE PROJECT HAS VERY LIMITED SUPPORT」 ，所以也许搬家总是好的。而在 fish，我则在尝试 starship。

但是 fish 则没有那么完善，fish 自带良好的 tab 补全，但是代价是没有人试图做的更好。我很喜欢 fzf-tab 插件，他能允许你在 tab 补全时多选。fish 当然也有 fzf 插件，也有人在尝试做这个事情，但是看起来由于「searching completions is better left to the fish-shell devs」被 closed 了（https://github.com/PatrickF1/fzf.fish/pull/293）。而至于 fish 自己，则有一个 10 年老 issue： https://github.com/fish-shell/fish-shell/issues/1898。

另一个问题是 git status，p10k 使用 git_status 来获取 git status，并且使用 lazy load 手段来避免在过大项目时的卡顿。同时，他有良好的情况处理和不同颜色的高亮，比如显示 rebase cherry-pick merge 的状态。

starship 在速度上到也还好，但缺乏对状态机的提示。我恰好这两天在处理一次大型的合并操作（https://github.com/guttatus/rustsbi/pull/1），在 fish 下这简直是灾难，我只能选择临时切回 zsh 来完成相关工作。

我能理解为什么 P10K 开发者打出「LIMITED SUPPORT」，一方面 P10K 在这么多年的开发下已经足够好，另一方面 zsh 也许是一个好的 shell，但是绝对不是一个好的语言，维护这样大的项目需要耗费相当大的精力。

至于 Fish，看起来他们最近在尝试从 Python 迁移到 Rust，而他们的 Rust 还在早期阶段，似乎并不是很能接受贡献。而我也不清楚如果我给 Python 的贡献，是否会迁移到 Rust 版本。而 Starship，我也许会在这两天尝试做一些修改，他们并不是用 gitstatusd 而是 gitoxide，也许可能会有做不到的事情。

按理来说，我的生产生活基于这些项目和工具，我应该积极投身到相关维护中去。只可惜自己能力时间有限，只能感谢各位开发者的贡献。

本文只是吐槽本人在使用 fish 时遇到的困难，并非对于相关项目有意见。