Creling

To be honest, I think hierarchy tags (i,e. #a/b) are better than the current used organization system (i.e. tags + lists).

@jacobgkau > I used to prefer folder structures, but after writing my own bookmark manager with folders, I'm starting to wish that I had tags so I could find things...

Well, I have change `omnibox-ui-max-autocomplete-matches` to 12 but Falcon still show only 6 entries, while `historysearch` could show hundreds entries.

> 扩大了“退款成功”和“交易关闭“的忽略账单范围。对于支付宝账单而言，有没有可能误伤一些本该记录的交易？ > > /cc @gaocegege 我的观点是，状态为“退款成功”和“交易关闭“的交易，本就应该考虑忽略它们，如果可能会误伤一些本该记录的交易。应该对这些交易额外添加豁免。 也就是说，对“退款成功”和“交易关闭“状态的交易的处理应该是一个白名单机制：对一部分不该忽略的交易添加白名单，豁免忽略。而不是黑名单机制：手动提交应该忽略的交易。无论如何，“退款成功”和“交易关闭“状态的交易中，应该忽略的交易占了大多数，而这些应该忽略的交易的特征非常复杂，如果手动添加，非常容易遗漏。 我们目前可能还没有找到，状态为“退款成功”和“交易关闭“，但不应该忽略的交易，如果找到了，把这些交易按照特征添加进白名单并不复杂。

关于这个pr，有什么新的进展或者需要讨论的东西吗？

> 但很不幸，我们当前并不能配置“白名单”的规则，配置文件中只支持主动忽略某些交易。 这里的黑名单和白名单都是指代码中硬编码的规则。 目前的做法是： ```go if order.Metadata["status"] == "退款成功" && order.Category == "退款" { ... 忽略该笔交易 ... } ``` 这种写法没有忽略掉很多该被忽略的交易（比如，状态为 "退款成功" 但Category为"餐饮美食"的饿了么支付宝退款），那么，与其修改成： ```go if order.Metadata["status"] == "退款成功" && (order.Category ==...

那么如果按照下面的方式修改现有代码，是否可以被接受？ ```go if order.Metadata["status"] == "退款成功" && (order.Category == "退款" || order.Category == "餐饮美食") { ... 忽略该笔交易 ... } ``` 本质上，我认为，对于"退款成功"状态的交易，更有可能是应该忽略的，而不是不应该忽略的。因此，“scope太小导致未忽略该忽略的“比”“scope太大导致忽略了不该忽略的“发生的情况更多（我已经在饿了么和闲鱼上遇到了两个未忽略应该忽略的case）。不过，我尊重开发者的意见 :) 为所有规则添加一个`ignore: false`确实是一个好主意，但每个provider是单独解析规则的，目前还没有时间为每一个provider都添加一个`ignore: false`，如果只为alipay添加，相当于alipay有了独特的功能语法，似乎不太优雅。 --- 题外话，不同provider支持的不同“方言语法”确实有点儿影响体验。比如WeChat支持用`Tag`来指定item的标签，而对于Alipay，虽然`double-entry-generator`的文档表示同样使用`Tag`来指定标签，但实际上需要使用`Tags`（P.S., 在Beancount v3中，取消了一个item支持多个tag的功能，现在一个item只支持一个tag），确实也在考虑，在保持后向兼容的情况下统一一下语法。