前两天收到一份邮件，标题写着 Google Translator Toolkit to be shut down on December 4, 20191，感叹又一款良心服务要终结其生命了。虽然不常用 Google 翻译工具包，甚至很长时间这个翻译工具都偷偷的被隐藏在翻译页面的角落里面，但是不得不说这个工具曾经帮助我翻译过不少文档内容，也非常适合学习。Google 翻译工具包提供上传文档自动翻译，术语翻译等等功能，结合 Google Translate 的帮助能非常快速的辅助完成一篇文档的翻译。在自动翻译完成的基础上可以人工的进行修改润色。更甚至可以添加好友一同翻译，将文档分享给他人。至今为止我也只有在 Google 翻译工具包中体验过如此完整的翻译体验。
很多其他的翻译工具大多只能够提供字符串的辅助翻译，比如之前帮别人翻译过 Android 应用内文本，这些工具都非常的简陋，甚至有些术语都不能自动帮忙翻译，还需要一个字一个字的输入。虽然 Google 在邮件中给出了一些 alternative 但我只想说这些工具要么就是限制平台的，要么就看起来不像是一个完整的产品。体验没有一个能比得上 Google Translator Toolkit.
这些网站多多少少我都有用过，目前 crowdin 做的还不错，有机器翻译自动提示，格式化处理的也比较好，快捷键也很合适。
另外开源版本的 Pootle，也有不少人推荐，用 Python + Django 写的。不过还没有尝试。
另一个开源的本地化工具 Weblate
在 sudo add-apt-repository 添加 PPA 时突然遇到 gpg 添加 key 失败，大概知道可能是因为网络问题，但是这个问题在我家里的网络一直存在，非常恼人。
gpg: keyserver receive failed: Server indicated a failure
所以我想从根本上解决这个问题，这个问题的根源可能是因为网络问题导致 gpg key 没有被导入到本地。所以如果能够手动下载 gpg public key 然后手动导入不就可以了？
所以随意打开一个 PPA，比如
在页面中 Technical details about this PPA 下方有 Signing key 点击该链接会跳转到一个签名的 key 列表，在该列表中找到报错内容中的 KEY
W: GPG error: http://ppa.launchpad.net/eosrei/fonts/ubuntu bionic InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY ADA83EDC62D7EDF8
复制该链接，然后使用下面的命令：
curl -sL https://keyserver.ubuntu.com/pks/lookup\?op\=get\&search\=0xada83edc62d7edf8 | sudo apt-key add -
等出现 OK 即可。注意这个 URL 中的 key 需要在前面加上 0x，否则会找不到该 key.
Ubuntu 或者其他一些 Linux 发行版 (Debian/Ubuntu/Linux Mint) 会内置 Google Noto Color emoji font，如果没有也可以直接通过一个命令直接安装 Noto Color emoji.
首先要安装支持 Emoji 的字体，个人比较喜欢 Google Noto Color Emoji，这是 Google 开源的用于 Android 的字体。并且支持力度一直都非常大。
直接安装
sudo apt install fonts-noto-color-emoji
或者从这里下载字体文件：
将字体文件放到 ~/.fonts 目录中。
然后运行 sudo fc-cache -f -v
Symbola font 可以将绝大部分 emoji 显示为单色的图案。
Ubuntu 系安装：
sudo apt-get install ttf-ancient-fonts
Twitter 的 emoji 方案：
sudo apt-add-repository ppa:eosrei/fonts
sudo apt-get update
sudo apt-get install fonts-twemoji-svginot
另一种可选方案：
Ubuntu 上可以使用 EmojiOne 来输入 Emoji
PPA:
sudo add-apt-repository ppa:ys/emojione-picker
sudo apt-get update
sudo apt-get install emojione-picker
如果在 Ubuntu 18.04 下安装 PPA 有问题，参考这里 解决。
先将 apt source 下的内容改成
sudo vi /etc/apt/sources.list.d/ys-ubuntu-emojione-picker-bionic.list
修改为
deb http://ppa.launchpad.net/ys/emojione-picker/ubuntu xenial main
然后再安装
sudo apt install emojione-picker -t xenial
在安装了 Noto Color Emoji 之后，记得需要在 Chrome 的设置中将 Chrome 的字体设置成 Noto 字体。
Java 8 新特性：
还有 interface 中的 static 和 default 方法。
Java 8 允许在接口中定义默认方法。
interface Collection {
void add();
default void debug(){
System.out.println("put the key in");
}
}
和接口中定义的其他方法一样，default 方法默认是 public
接口是用来定义类的行为的，如果要在接口中新添加方法，那么所有实现此接口的类都需要强制的实现新添加的方法。而 default 方法就可以规避该问题。
当一个类实现的多个接口定义了相同的 default 方法，那么编译时会失败。需要子类 Override 该方法实现。在子类中可以通过 Interface.super.xxx() 方法来调用接口的 default 方法。
@Override
public void turnOnAlarm() {
Vehicle.super.turnOnAlarm();
Alarm.super.turnOnAlarm();
}
除了 default 方法，Java 8 也允许在接口中定义 static 方法。
接口中的静态方法属于类，在接口中定义 static 方法和在类中定义一样。
因为 Java 不支持多继承，所以在遇到一些代码共享的时候，就不能通过多继承来实现，通常的做法是定义一个静态类，包含可能被多个类使用到的共同的方法，比如 Java 中的 Collections 类。
而通过接口中的 static 方法可以提高代码的 cohesion，将相关的逻辑集中到一起，而不用另外定义一个 Object。
同样 Abstract 类也能做到，但是和抽象类的区别在于，抽象类是有 Constructors, state, behavior 的。
理想状态下，接口不应该封装具体的行为，只应该用来定义某类型的公开接口。
但是为了弥补 Java 不能多继承而带来的一些缺点，Java 8 中引入接口的 default 和 static 方法，也肯定是 JDK 工程师仔细考量后的一个权衡。
在上一篇 GraphQL 使用 中了解了 GraphQL 大致用法，如果要更加深入的了解 GraphQL ，那就不得不重新从 Schema 来认识 GraphQL，说到底 GraphQL 还是一个强类型定义，客户端可操作的类型都是需要提前定义好的，这个结构就是这篇文章的重点 – Schema.
因为已经有很多的语言已经实现了 GraphQL，官方不能以某一个语言来具体表达，所以他们自定义了一套表示 GraphQL Schema 的简单表达。1
GraphQL 对数据支持的操作：
GraphQL 中的 Type 可以分成，Scalar Type（标量类型），和 Object Type（对象类型）。
GraphQL 自带一些默认类型
true or falseID，那么不可读。不同的实现，可能会有自己的类型，比如 Date 类型，具体实现要看各个语言。
枚举类型，将输入固定为几个预定义的值。
GraphQL 可以表达非空，使用 ! 即可。
type Character {
name: String!
appearsIn: [Episode]!
}
或者使用如下来表达非空数组
myField: [String]!
或者可以使用
myField: [String!]
来表达数组可以为空，但是元素不能为 null
GraphQL 支持 Interfaces，直面来看就是接口，GraphQL 可以定义接口，每个接口可以有不同的实现。 [^interface]
[^interface](https://graphql.org/learn/schema/#interfaces)
类型修饰符用来修饰类型。
比如定义 User 对象。
type User {
id: ID!
name: String!
articles: [Article]!
bookNames: [String!]!
}
分别表示了：
https://graphql.org/learn/schema/ ↩
之前的文章 PostgreSQL 初识 和 PostgreSQL 数据类型 大致的把 PostgreSQL 了解了一下，那么接下来就是真正地把它用起来。
开源迁移工具，通过一行命令即可做到无缝迁移
PGLoader 原本可以将不同数据源导入到 PostgreSQL 数据库，MySQL 只是它支持的一种。PGLoader 使用 PostgreSQL 的 COPY 命令将数据从源数据库或文件复制到目标 PostgreSQL 数据库中。
Debian 系：
sudo apt-get install pgloader
验证
$ pgloader --version
pgloader version "3.5.2"
compiled with SBCL 1.4.5.debian
或者使用 Docker
docker pull dimitri/pgloader
docker run --rm --name pgloader dimitri/pgloader:latest pgloader --version
docker run --rm --name pgloader dimitri/pgloader:latest pgloader --help
或者参考官方自行编译安装。1
PGLoader 通过命令来复制，所以必须要配置一个 PGLoader 可以访问 PostgreSQL 的用户来方便执行命令。PostgreSQL 使用角色来管理数据库访问，需要配置该角色与 PGLoader 命令执行用户同一名称。之前提到过 PostgreSQL 普通数据不要轻易使用超级用户来管理，但是 PGLoader 需要使用非常多的权限来管理、访问、加载表中数据，因此需要授予 PGLoader 超级用户权限。
创建超级用户 pgloader 使用 -P 来为用户创建密码：
sudo -u postgres createuser --superuser pgloader -P
创建数据库，准备导入该数据库：
sudo -u postgres createdb quotes -O pgloader
PostgreSQL 准备工作结束，假设 MySQL 的超级用户和密码都已经设置好，并且该用户拥有要迁移的数据库所有权限。本地执行验证：
mysql -h localhost -u root -p
注意在任何会影响到数据库数据完整性的操作前，备份数据库，虽然 PGLoader 迁移时并不会修改或者删除数据，但是必要的备份一定不能掉以轻心。使用 mysqldump 来备份数据库。
在本地做一个简单的测试，本地 MySQL 数据库 quotes:
mysql://root@localhost:3306/quotes
如果想要把这个数据库迁移到 PostgreSQL 中。
postgresql://user:pass@localhost:5432/quotes
执行
pgloader mysql://root:password@localhost:3306/quotes postgresql://pgloader:password@localhost:5432/quotes
pgloader 接受两个参数，一个是源数据库连接，一个是目标数据库连接。
➜ build/bin/pgloader mysql://root:password@localhost:3306/quotes postgresql://postgres:password@localhost:5432/quotes
2019-09-07T09:56:38.030000+08:00 LOG pgloader version "3.6.26cc9ca"
2019-09-07T09:56:38.047000+08:00 LOG Migrating from #<MYSQL-CONNECTION mysql://root@localhost:3306/quotes {1005B1DE43}>
2019-09-07T09:56:38.048000+08:00 LOG Migrating into #<PGSQL-CONNECTION pgsql://postgres@localhost:5432/quotes {1005D6D903}>
2019-09-07T09:56:38.335000+08:00 LOG report summary reset
table name errors rows bytes total time
----------------------- --------- --------- --------- --------------
fetch meta data 0 1 0.100s
Create Schemas 0 0 0.004s
Create SQL Types 0 0 0.005s
Create tables 0 2 0.026s
Set Table OIDs 0 1 0.004s
----------------------- --------- --------- --------- --------------
quotes.quotes 0 100 15.9 kB 0.058s
----------------------- --------- --------- --------- --------------
COPY Threads Completion 0 4 0.058s
Index Build Completion 0 0 0.000s
Reset Sequences 0 0 0.015s
Primary Keys 0 0 0.000s
Create Foreign Keys 0 0 0.000s
Create Triggers 0 0 0.001s
Set Search Path 0 1 0.001s
Install Comments 0 0 0.000s
----------------------- --------- --------- --------- --------------
Total import time ✓ 100 15.9 kB 0.075s
校验数据
sudo -u postgres psql
\c quotes
select * from quotes.quotes limit 1;
这里就会发现，导入的数据没有默认到 public Schema 下，而是在自己的 Schema 下。在 PostgreSQL 中，每当我们创建一个数据库，都会自动产生一个 public Schema，当登录数据库查询时，如果没有加特定的 Schema，则会默认使用 public.
在使用的时候有几个问题，Debian 源中的 pgloader 有些老，3.5.2 的版本似乎有些 Bug，我在使用时报错
2019-09-07T02:03:45.044000Z LOG Migrating from #<MYSQL-CONNECTION mysql://root@localhost:3306/imdb {1005805E43}>
2019-09-07T02:03:45.047000Z LOG Migrating into #<PGSQL-CONNECTION pgsql://pgloader@localhost:5432/quotes {1005A56E73}>
KABOOM!
INFO: Control stack guard page unprotected
Control stack guard page temporarily disabled: proceed with caution
What I am doing here?
Control stack exhausted (no more space for function call frames).
This is probably due to heavily nested or infinitely recursive function
calls, or a tail call that SBCL cannot or has not optimized away.
PROCEED WITH CAUTION.
所以最后不得不直接使用源码编译使用最新版。
➜ build/bin/pgloader --version
pgloader version "3.6.26cc9ca"
compiled with SBCL 1.4.5.debian
该版本没有任何问题。
同 pgloader 还有其他一些命令：
pgloader./test/sqlite/sqlite.db postgresql:///newdb
PGLoader 是一个可以高度配置的工具，除了上面提到的简单命令行迁移之外，PGLoader 还提供了强大的配置文件来帮助迁移。PGLoader 可以使用一个文件来配置告诉 PGLoader 如何迁移文件，该文件可以配置 PGLoader 的运行方式，并且可以执行更加复杂的迁移。
创建文件 vi pgload.load:
LOAD DATABASE
FROM mysql://root:einverne.@localhost:3306/wordpress
INTO pgsql://pgloader:einverne.@localhost:5432/quotes
WITH include drop, create tables, create indexes, workers = 8, concurrency = 1
ALTER SCHEMA 'wordpress' RENAME TO 'public'
;
注意最后的 ; 一定要加。
解释：
LOAD DATABASE 指定从数据库加载FROM 源数据库INTO 目标数据库WITH 指定 PGLoader 行为
include drop，迁移过程中，PGLoader 会删除目标 PostgreSQL 数据库中在源数据库中同名的任何表。注意备份。create tables, 配置 PGLoader 根据源数据库数据在目标数据库中创建新表，如果使用 create no tables，则需要手动在目标数据库中创建好对应的表。ALTER SCHEMA, 在 WITH 语句之后，配置特定 SQL 来告诉 PGLoader 执行其他操作。更多更加详细的配置可以参考官方文档
创建完该文件后使用如下命令执行
pgloader pgload.load
下面也是可选的方案，不过没有仔细研究
很多人都知道 GraphQL 起源于 Facebook，但是似乎很少中文材料提到 GraphQL 出现的契机，我在看完这个纪录片 之后才对 GraphQL 的出现有更加深刻的了解。都知道当年 Facebook 的移动客户端都是网页，随着移动互联网发展，Facebook 网页实现的客户端性能和体验受到非常严重的影响，所以后来不得不去做原生的应用。那么这个时候就遇到了一个问题，原来直接使用网页，那么不同客户端用的接口都是给网页用的，最多做一下屏幕的适配，但是如果使用原生的应用，那么必然会需要设计不同的 API，而 Facebook 的工程师发现，对于复杂的 Feed 流，评论等等，用 RESTful 接口将是一个灾难，所以一帮人开始设计一种查询语言，这就是后来的 GraphQL。也应该纠正一下 Facebook 那帮工程师，只是开源了一份设计和一份实现，但他们万万没有想到开源社区的力量，就像片中 Nick Schrock 说的那样，他低估了社区的力量，在短短的几个月，几年时间中，GraphQL 就已经有了非常多语言的支持，周边应用也非常丰富。原来在脑海里的想法，都没有到生产环境中用过，就这样在所有社区的人的努力下成为了改变这个行业的一部分。
在了解 GraphQL 的过程中，看到一个非常有意思的比喻，经常有人会问起 GraphQL 和 RESTful 接口的区别，如果用去餐厅吃放，自助餐或者点餐来比喻，那么 GraphQL 就像是自助餐，你想要吃什么去餐盘中自己选择，而 RESTful 就像是点菜，需要看菜单，然后根据菜单选择。虽然两者都能吃饱，但是使用感受完全不同。1 当然这篇文章就不再继续讲 GraphQL 是什么，有什么用了，之前的 文章 也列了很多资料，差不多可以了解到它的具体使用场景了。这篇文章重点在于怎么把 GraphQL 用到实际项目中。
GitHub 上的 awesome-graphql 项目列举了太多的开源实现，从 c++, java, 到 python, nodejs, ruby 等等，这里我就选择上手最快的 python 更具体一些是 Django 来体验一下 GraphQL 和 Django 结合的效果。
先放上代码：
原始项目有些时间了，所以更新了一下，加了一些其他特性。
主要借用的是这个项目：
Django 支持 https://github.com/graphql-python/graphene-django/
GraphQL 的查询语法。
最常见的查询，请求方根据 Schema 定义结构，查询：
query {
allPeople {
id
username
}
}
结果和查询结构相同，包裹在 data 结构中：
{
"data": {
"allPeople": [
{
"id": "1",
"username": "steve"
},
{
"id": "2",
"username": "aholovaty"
},
{
"id": "3",
"username": "swillison"
},
{
"id": "4",
"username": "gvr"
},
{
"id": "5",
"username": "admin"
}
]
}
}
GraphQL 的接口是有类型定义的，对于上面的查询可以总结出
type RootQuery {
allPeople: Person
}
type Person {
id: int
username: String
}
官方的说法 叫做 Arguments，参数化请求。
比如查询条件为 id 为 5 的用户信息
query {
person(id: "5") {
id
username
email
}
}
结果是
{
"data": {
"person": {
"id": "5",
"username": "admin",
"email": "[email protected]"
}
}
}
结构
type RootQuery {
person(id: int) : Person
}
GraphQL 可以有不同的参数类型，这取决于你的类型定义，Schema 定义。2 并且你可以自定义你的参数类型，只要你能够序列化该参数，这就使得 GraphQL 扩展性大大增强。
没有看到官方的翻译，暂且称之为“别名”好了 [^aliases]，某些情况下想要重写结果的 KEY，可以使用改方式来实现。
假如查询的时候要查两个用户的信息
query {
person(id: "5") {
id
username
email
},
person(id: "4") {
id
username
email
}
}
这么查肯定是会返回两个 person 的 key 的 JSON，那么就会有问题，GraphQL 允许我们重命名
query {
p5: person(id: "5") {
id
username
email
},
p4: person(id: "4") {
id
username
email
}
}
返回值是这样的：
{
"data": {
"p5": {
"id": "5",
"username": "admin",
"email": "[email protected]"
},
"p4": {
"id": "4",
"username": "gvr",
"email": "[email protected]"
}
}
}
[^Aliases](http://graphql.org/learn/queries/#aliases)
Fragments Android 里面也用了这个名词，我也不知道怎么翻译，暂且叫做“片段”好了，为什么要有 Fragments 呢？ 就是因为要重用，看到上面请求两个用户的 Query 语句了吗？其中每个用户都想要请求其 id, username, email，这些参数是不是每次都要手写，假如这个 Person 信息不仅包含着三个，还有很多，假如不止请求两个用户信息，难道还要复制 N 遍，这显然是不合理的，所以 GraphQL 引入了 Fragments 概念，可以定义片段，然后再复用。
{
p4: person(id: "4") {
...personFields
},
p5: person(id: "5") {
...personFields
}
}
fragment personFields on PersonType {
id
username
email
fullName
firstName
lastName
friends {
id
username
}
}
结果就是对应的
{
"data": {
"p4": {
"id": "4",
"username": "gvr",
"email": "[email protected]",
"fullName": "Guido van Rossum",
"firstName": "Guido",
"lastName": "van Rossum",
"friends": [
{
"id": "2",
"username": "aholovaty"
},
{
"id": "3",
"username": "swillison"
}
]
},
"p5": {
"id": "5",
"username": "admin",
"email": "[email protected]",
"fullName": " ",
"firstName": "",
"lastName": "",
"friends": []
}
}
}
如果再进一步，既然能够定义 Fragments 了，那么在其中定义变量也是可以的吧。
query person($first: Int = 2) {
p4: person(id: "4") {
...personFields
},
p5: person(name: "admin") {
...personFields
}
}
fragment personFields on PersonType {
id
username
email
fullName
friends(first: $first) {
id
username
}
}
结果是这样的
{
"data": {
"p4": {
"id": "4",
"username": "gvr",
"email": "[email protected]",
"fullName": "Guido van Rossum",
"friends": [
{
"id": "2",
"username": "aholovaty"
},
{
"id": "3",
"username": "swillison"
}
]
},
"p5": {
"id": "5",
"username": "admin",
"email": "[email protected]",
"fullName": " ",
"friends": [
{
"id": "1",
"username": "steveluscher"
},
{
"id": "2",
"username": "aholovaty"
}
]
}
}
}
要使用变量，需要有三个步骤：
$ 操作符的 $variableName 变量名variableName: value 参数以可以传输的格式（通常是 JSON) 传递给查询变量在定义时需要注意会在后面跟着 : type 来表示该变量的类型。定义的变量只能是这些类型
对于复杂变量，需要到 Schema 中知道该变量的内容。这部分可以参考 Schema.
变量如果是必须的，那么需要在变量类型后面增加 ! 来表示
在上面的例子中也能看到，在 Query 的时候，有些情况下可以省略最前面的 query 关键字，这个 query 关键字在 GraphQL 中叫做 operation type，之所以叫做 type，是因为这只是查询，到后面还有 mutation （修改）, subscription 等等。这个操作类型隐含了此次操作的具体动作，比如说是查询，还是修改，还是订阅等等。
接在 query 关键字后面的是 operation name，操作名，该名字定义了此次查询的含义，比如上面的例子就是查询 person 信息。operation name 就像是大部分语言里面的方法，operation name 在获取多个文档时才是必须的，但是非常建议给予每一个查询一个名字，operation name 在调试服务端程序时非常有用，可以快速定位问题。
插入或者更新数据，和查询类似，使用 mutation operation type， 后面接 operation name，再就是传参，以及定义返回值。
mutation createCategory {
createCategory(name: "Milk") {
category {
id
name
}
}
}
class CreateCategory(graphene.Mutation):
"""
"""
class Arguments:
name = graphene.String(required=True)
category = graphene.Field(CategoryType)
def mutate(self, info, **kwargs):
name = kwargs.get('name')
category = Category(name=name)
Category.save(category)
return CreateCategory(category=category)
class UpdateCategory(graphene.Mutation):
"""
mutation updateCategory {
updateCategory(id: "5", name: "MilkV2") {
category {
id
name
}
}
}
"""
class Arguments:
id = graphene.ID()
name = graphene.String(required=True)
category = graphene.Field(CategoryType)
def mutate(self, info, id, name):
ca = Category.objects.get(pk=id)
ca.name = name
ca.save()
return UpdateCategory(category=ca)
class Mutation(graphene.ObjectType):
create_category = CreateCategory.Field()
update_category = UpdateCategory.Field()
Mutation 和 Query 有一个显著的差异，Query Field 会同时查询，而 Mutation Field 只会顺序，一个接一个查询。
其他 Python 实现的 GraphQL
用 node 实现第一个 GraphQL
GraphQL with Flask
JSON API
这里是一些已经实现 GraphQL 的公开的 API
决策表的列定义。
A string identifying a rule flow group. In rule flow groups, rules can fire only when the group is activated by the associated rule flow. Example: ruleflow-group "GroupName"
A string identifying an agenda group to which you want to assign the rule. Agenda groups allow you to partition the agenda to provide more execution control over groups of rules. Only rules in an agenda group that has acquired a focus are able to be activated. Example:
agenda-group "GroupName"
Agenda Groups 是一种分区规则的方法，任何时候只有一组规则拥有 Focus，只有拥有 Focus 焦点的规则才会生效。
agenda-group 默认值 MAIN，类型是 String，可以如下方式定义：
rule "Is of valid age"
agenda-group "GroupA"
when
Applicant( age < 18 )
$a : Application()
then
$a.setValid( false );
System.out.println("GroupA fired age < 18");
end
Agenda-Group 像栈一样工作，当给定 Group 设置 Focus 时，该 Group 会被放到栈顶。
元数据列，默认情况下元数据列是隐藏的。可以在决策表的列属性中显示。
ripgrep（简称 rg)，是一个用 Rust 实现的命令行搜索工具，可以通过正则来搜索当前的目录。默认情况下 ripgrep 会遵循 .gitignore 的内容，并且自动跳过隐藏的文件目录，以及二进制文件。 ripgrep 原生支持 Windows, MacOS, Linux。ripgrep 和其他流行的搜索工具非常相似，比如 The Silver Searcher, ack 和 grep.
目前 Linux 下可用的搜索工具非常多，GNU 中的 grep， ack-grep，The Silver Searcher 等等，而 rg 的优势在于快。
ripgrep 是真正的快，我在一个有 26G 代码的目录中查找一个方法也可以在几乎秒级的速度找到，所以我经常用来搜索不确定调用关系，但代码又分布在不同项目中时使用ripgrep 遵循 .gitignore，在默认情况下会跳过二进制文件，隐藏的文件目录，不会追踪软链接，更进一步加快了速度ripgrep 支持 Unicode, 可以搜索压缩文件，还可以自己选择正则表达式匹配引擎，比如 PCRE2安装的内容直接参考官方页面 即可。
brew install ripgrep
来看看 rg 的通用格式
USAGE:
rg [OPTIONS] PATTERN [PATH ...]
rg [OPTIONS] [-e PATTERN ...] [PATH ...]
rg [OPTIONS] [-f PATTERNFILE ...] [PATH ...]
rg [OPTIONS] --files [PATH ...]
rg [OPTIONS] --type-list
command | rg [OPTIONS] PATTERN
最不用记忆的就是直接：
rg "keyword"
会显示当前目录下的搜索内容，会打印出文件名及关键字出现的行数。
和 grep 命令类似，也有三个打印出上下行的选项
-A NUM 打印匹配行后面 after N 行-B NUM 打印匹配行前面 before N 行-C NUM 打印匹配行前后 N 行使用 -e REGEX 来指定正则表达式
rg -e "*sql" -C2
默认 rg 会忽略 .gitignore 和隐藏文件，可以使用 -uu 来查询所有内容：
rg -uu "word" .
使用 -c 来显示匹配的次数：
rg -c "word" .
结果会在文件名后面增加一个次数。
可以使用 -t type 来指定文件类型：
rg -t markdown "mysql" .
支持的文件类型可以通过
rg --type-list
来查看。
看到这里，有些读者可能要问假如我要在两个文件类型中查找呢，这个时候 -t 参数就无法满足了，需要引入新的 -g 参数，man rg 看一下 -g 就知道该选项后面跟着一个 GLOB，正则表达式，包括或者去除一些文件或者目录。比如要在 md 文件或者 html 文件中查找 “mysql” 关键字
rg -g "*.{md,html}" "mysql"
注意这里是花括号。
使用 -l 来打印文件名
rg -l -w "word" .
相反的是如果要打印没有匹配内容的文件名
rg --files-without-match -w "word" .
使用 -s 选项来启用大小写敏感
rg -s "word" .
使用 -i 来关闭大小写敏感。
使用选项 -v 来显示不包含关键字的行
rg -v "word" .
添加 -w 参数仅显示该单词的内容，该选项等同于在搜索 Pattern 前后加上 \b，这样可以避免因为模糊搜索而导致的不精确。
rg -w "myword" .
比如搜索 abc，可能有些单词包含 dabce ，那么也会被搜索出来，而加上 -w 就不会搜索出来了。
如果只想要查找文件名中的关键字可以联合 --files 使用。
--files 选项会打印出 rg 将会搜索的所有文件名，包含路径，那如果想要查找文件名中是否包含某个关键字，就可以使用
rg --files | rg regular_expression
比如有一个需求，替换所有文件中的一个字符串到另外一个词，可以使用如下的方式。
rg foo --files-with-matches | xargs sed -i 's/foo/bar/g'
在 macOS 上默认的 sed 有一些兼容性，需要修改为
rg foo --files-with-matches | xargs sed -i'' -e 's/foo/bar/g'
有两个方法查看 rg 使用
man rgtldr rgfzf 的介绍看这篇文章，这篇文章主要总结一下 Fzf 在 vim 下面的使用。
安装过程就不再说，安装后 :help fzf 可以查看所有帮助。
fzf-vim 安装之后， :FZF 命令会被添加。
" 在当前目录搜索"
:FZF
" 在 home 目录搜索"
:FZF ~
" fzf 全屏"
:FZF!
常用的配置 :help 中都能看到。
" An action can be a reference to a function that processes selected lines
function! s:build_quickfix_list(lines)
call setqflist(map(copy(a:lines), '{ "filename": v:val }'))
copen
cc
endfunction
let g:fzf_action = {
\ 'ctrl-q': function('s:build_quickfix_list'),
\ 'ctrl-t': 'tab split',
\ 'ctrl-x': 'split',
\ 'ctrl-v': 'vsplit' }
" Default fzf layout
" - down / up / left / right
let g:fzf_layout = { 'down': '~40%' }
let g:fzf_history_dir = '~/.local/share/fzf-history'
常用命令
Files :FZF
和 ctrip.vim 类似，使用回车， Ctrl-T, Ctrl-X 或者 Ctrl-V 可以分别在当前窗口，标签页，水平分隔或者垂直分隔窗口中打开。
FZF_DEFAULT_COMMAND 和 FZF_DEFAULT_OPTS 环境变量也会被使用。
跳转到 Buffer 内的某一行
:Lines
或者是当前 Buffer 内的行
:BLines
查找 Buffers
:Buffers
查找 Windows:
:Windows
查找可用的命令
:Commands
Normal Mode Mappings
:Maps
:help fzf