IceCodeNew
IceCodeNew
> You can still view the abstract and other basic information if you have not subscribed or bought the paper. You still can visit these sites without proxy, I'm sure...
> > You still can visit these sites without proxy, I'm sure most of them are not blocked. > > Actually, the change in this PR doesn't affect my setup....
> If merged And BTW, this PR is not going to be merged. Not until the OA sites have been separate from the scholarly sites which require a subscription.
> > And I gradually find out that pushing things too far from practicality is not going to serve any good. > > I don't think removing a bunch of...
根据我对 #28 #256 讨论的印象，确实关于 include 语法的改变是被讨论者接受的。 我个人完全支持这一提案。
> * 如何处理「需要 include 同时具备某几个属性的规则」的情况？ 没看懂你这句话，你是指在某种场景下这种语法补充可能导致问题吗？如果说是具体实现，我觉得不难。 > * 似乎「每新建一个文件，都需要同时往 `geolocation-cn` 和 `geolocation-!cn` 里写入 `include`」比较啰嗦，是否有更方便的方式？（如果要改，就往简单的方向改） 这个问题应该超出了这个 issue 提议的范围，是不是可以另开一个 issue 讨论？
> 缩进破坏就比较大了吧，成本也比较高。注释大概就够用了 > > ``` > # google > google.com > > # google email > gmail.google.com > ``` 我觉得这个不就是答案了吗 只要求局部有序就可以了，不同子公司之间用注释区隔，然后每个小区隔内做到字典序排序就好了。
> > 只要求局部有序就可以了，不同子公司之间用注释区隔，然后每个小区隔内做到字典序排序就好了。 > > 外面也需要，因为这样 attr 好打一点 没 get 到，你能举个例子吗？
> 比如 geolocation-cn 就是一个集合的定义，如果允许修剪类型不就破坏掉这个概念了吗 附议。
我觉得这边的讨论有些陷入停滞了，目前 #255 还没有人审核过，我觉得现在主要影响进展的问题有两点： 1. attr 被视为一个实验性的功能，但很多使用到本项目数据的第三方项目都在 push 本项目使用 attr 属性 2. 我们不太愿意改变之前对诸如 `geolocation-cn` 这些域名分类的定义 但是总的来说，这些都不妨碍 #255 得到推进，从 PR 的主要因素来说，这个 PR 主要做的就是构建流程的改进，而这些改进在我看来都很实用且必要。 我希望 @Loyalsoldier 可以确认一下 #255 是否能够拆分成几个小的 PR，这样我们可以绕开很早就有且一直难以得到定论的问题，先把相关的功能实现起来。 比如 #255 对...