fix(config_compiler): "/" mistaken as path separator in merged map key

[kionz]

Fixes #190

[lotem]

The variable name sounds like a "node" but it's not. Name it using a verb phase, for example "find_target_node"?

[lotem]

If you null-check the result of cow_node(target, path), this would be unnecessary.

[lotem]

The name target is used for another (argument) variable in lambda, which can refer to a different config node. Better differentiate the name.

[kionz]

done

[lotem]

LGTM

[lotem]

I did some test. With the fix, this works:

# luna_pinyin.custom.yaml
patch:
  __include: kuangh:/patch
  punctuator/+/+:
    half_shape:
      '^': ['^', '……', '^_^']

It is an attempt to modularize the patch.
The included file can be found in this pull request
rime-aca/customize#3

One thing to note is the double /+ in the patch key.
The first /+ is the suffix operator "add", meaning the value node tree should be merged into the punctuator node tree recursively, instead of replacing the entire node tree and wiping out all other punctuations.
While the second /+ is to protect the first one from being consumed when merging the value node tree into the __include-ed node tree. Without the second suffix operator, the compiled patch would look like

patch:
  # other patched paths from kuangh:/patch
  punctuator:
    half_shape:
      '^': ['^', '……', '^_^']

That would mean replacing the punctuator node with just one half-shape symbol defined.
The second suffix operator can also be /= which overwrites patch contents under the same patch key punctuator/+ (with the same /+) if it also exists in the included patch.

My take-away from this example:
__include: infers an implicit __merge: if there are other sibling keys under the same map node.
My patch is equivalent to

patch:
  __include: kuangh:/patch
  __merge:
    punctuator/+/+:
      half_shape:
        '^': ['^', '……', '^_^']

In a __merge: operation, suffix operators in map keys are interpreted. The same happens to patch value if the patch key has a /+ suffix. (if there isn't a suffix operator in patch keys /= is implied)
If the string /+ or /= has to be a map key or the ending part of a map key, you can guard them with an extra suffix operator for one merge operation.

In real-life you may never have to include another patch to your patch. Knowing that you can and how to do so helps create complex, modular configuration with scripts or GUI tools.

[jiaojiaodubai]

从wiki的Configuration翻到此处，为方便后来者理解lotem给出的代码，在此稍作注解。

symbols文件

首先，Rime的共享文件夹（在Weasel中称作“程序文件夹”）中有一个名为symbols.yaml的文件，该文件有一个名为punctuator的根节点。punctuator罗列了键盘上各符号及其对应标点符号的映射关系，可供各输入方案导入使用，其结构为：

# symbols.yaml
# ...
punctuator:
  full_shape: # 全角符号
    # ...
  half_shape: #半角符号
    # ...
    '^' : { commit: …… }
    # ...
  symbols: # 特殊符号
    # ...
# ...

其中，puctuator/half_shape/'^':{ commit: …… }的意思是：半角符号状态下，按键Shift + 6将直接输出符号……。

schema文件

文件luna_pinyin.custom.yaml位于用户文件夹内，是明月拼音输入方案的用户自定义文件，用于修改位于共享文件夹的明月拼音输入方案luna_pinyin.schema.yaml的默认配置。
luna_pinyin.schema.yaml中有这样一段代码：

# luna_pinyin.schema.yaml
# ...
punctuator:
  import_preset: symbols
# ...

这里的import_preset:的作用与__include:类似，可以将外部文件的内容导入到import_preset:所在的父节点内，而非将外部文件的内容作为import_preset:的value（详见schema.yaml详解）。等同于如下的代码：

# luna_pinyin.schema.yaml
# ...
punctuator:
  full_shape: # 全角符号
    # ...
  half_shape: #半角符号
    # ...
    '^' : { commit: …… }
  symbols: # 特殊符号
    # ...
# ...

即luna_pinyin.schema.yaml采用symbols.yaml作为默认的符号配置，半角符号状态下Shift + 6将直接输出符号……。

custom文件

为了改变半角符号状态下Shift + 6的行为，使其变为可以选择^、……、^_^中的任意一个符号，该例子在luna_pinyin.custom.yaml文件中作了如下补丁：

# luna_pinyin.custom.yaml
# ...
patch:
  __include: kuangh:/patch
  punctuator/+/+:
    half_shape:
      '^': ['^', '……', '^_^']
# ...

其中__include: kuangh:/patch引入了kuangh.yaml的patch节点，该节点的内容详见rime-aca/customize/Kuang Reversed Lookup/kuangh.yaml。总之，kuangh:/patch的内容与标点符号无关，不会与下面的内容冲突。

第一次合并（punctuator → include）

根据自动应用补丁的规则，luna_pinyin.custom.yaml的代码

# luna_pinyin.custom.yaml
# ...
patch:
  __include: kuangh:/patch
  punctuator/+/+:
    half_shape:
      '^': ['^', '……', '^_^']
# ...

作用于luna_pinyin.schema.yaml之后，相当于把后者改写为：

# luna_pinyin.schema.yaml
__patch:
  __include: kuangh:/patch
  punctuator/+/+:
    half_shape:
      '^': ['^', '……', '^_^']

punctuator:
  full_shape: # 全角符号
    # ...
  half_shape: #半角符号
    # ...
    '^' : { commit: …… }
  symbols: # 特殊符号
    # ...

根据wiki/Configuration/補靪关于编译顺序的说明，__patch结点的编译顺序如下：

1. 把__include所指代的内容导入到__include所在的父节点。
2. 将__include导入的节点与__include同级的节点合并起来。

在上述第2步合并动作发生时，不仅__patch/punctuator与__patch/__include引入的节点会进行合并，而且__patch/punctuator的内部也发生合并。而__patch的默认合并行为是用它下面书写的节点直接替换目标节点，如果__patch/punctuator写为

# luna_pinyin.schema.yaml
__patch:
  punctuator:
    half_shape:
      '^': ['^', '……', '^_^']

punctuator:
  full_shape: # 全角符号
    # ...
  half_shape: #半角符号
    # ...
    '^' : { commit: …… }
  symbols: # 特殊符号
    # ...

那么尝试合并__patch/punctuator和luna_pinyin.schema:/puctuator时，__patch/punctuator将会直接替换luna_pinyin.schema:/puctuator：

# luna_pinyin.schema.yaml
# else root node
punctuator:
  half_shape:
      '^': ['^', '……', '^_^']
# else root node

为了避免这这种情况，保留luna_pinyin.schema:/puctuator原来的其它内容，代码__patch/punctuator/+/+中的第一个/+声明：节点__patch/punctuator/half_shape参与此次合并时会被追加到节点luna_pinyin.schema:/puctuator。此次合并后，__patch/__include的内容被导入到__patch，__patch/punctuator的一个/+在合并时被消耗：

# luna_pinyin.schema.yaml
__patch:
  #  ...
  # nodes in "__include"
  # ...
  punctuator/+:
    half_shape:
      '^': ['^', '……', '^_^']

punctuator:
  full_shape: # 全角符号
    # ...
  half_shape: #半角符号
    # ...
    '^' : { commit: …… }
  symbols: # 特殊符号
    # ...

第二次合并（punctuator → punctuator）

__patch用于修改与它同级的所有节点，此时__patch处于luna_pinyin.schema.yaml的根节点，因此它可以修改luna_pinyin.schema.yaml下的所有节点，这其中就包括luna_pinyin.schema.yaml:/punctuator这个节点。
如上一节（第一次合并）所述，经过__patch/__include的一次合并，原先的__patch/punctuator/+/+已经变为__patch/punctuator/+：

# luna_pinyin.schema.yaml
__patch:
  #  ...
  # nodes in "__include"
  # ...
  punctuator/+:
    half_shape:
      '^': ['^', '……', '^_^']

punctuator:
  full_shape: # 全角符号
    # ...
  half_shape: #半角符号
    # ...
    '^' : { commit: …… }
  symbols: # 特殊符号
    # ...

待到编译__patch时，剩下的这个/+就可用于将__patch/punctuator/half_shape追加到luna_pinyin.schema.yaml:/punctuator：

# luna_pinyin.schema.yaml
# else root node
punctuator:
  full_shape: # 全角符号
    # ...
  half_shape: #半角符号
    # ...
    '^': ['^', '……', '^_^']
  symbols: # 特殊符号
    # ...
# else root node

小结

我对本例作以下理解，不妥之处欢迎指正：

• __include命令包含一次合并行为，合并时会解释参与合并的所有节点及其子节点的含义。此时如果参与合并的节点及其子节点节点路径末尾含有/+、/=这样的合并行为标识符（姑且这么称呼），则这些标识符会在解释时被消耗一次。
• __include将其引入的节点与__include同级节点合并时，分两种情况：
  • 如果是map型节点：
    • 默认保留__include同级map节点内容，再追加被引入的map；如果原先已经有同key的map，则以__include引入的为准。
  • 如果是list型节点：
    • 默认清除__include同级list节点，并用被引入的list节点取代。

在本例中，__patch/puctuator是一个map节点，且与__include引入的map节点没有冲突，固然满足__include的合并规则。但在__include引起的合并发生时，作为__patch/puctuator的子节点，__patch/puctuator/half_shape合并到__patch/puctuator的具体行为必须得到解释。即必须说明：half_shape是作为整个value替换puctuator的value，还是half_shape作为puctuatorvalue的一部分被追加到puctuator中？你的选择决定了稍后__patch的行为。

综上，本例的patch出现“诡异的”两个/+是因为patch中含有__include，正是__include引起的合并事件导致patch内所有节点都被解释了一次，从而消耗了punctuator的/+，为了让补丁正常工作，我们不得不写两个/+。