Claudy Forrest

Results 56 comments of Claudy Forrest

> 主要的增加内容就是把每种方法都画出字符画图来,更便于理解 您好,您的修改很细致,但是您现在采用的文字格式的可视化导致页面无法渲染。您能够把您的可视化等部分用图片形式(最耗时 svg 格式)插入到页面中吗?如果您没有精力掌握 latex、typst、python 等可以输出矢量图的方法,您可以简单地在 Word、PowerPoint 或绘图软件中将您的可视化绘制出来,然后截图插入页面中。 您可以通过本页面的 checks 中的 netlify/oi-wiki/deploy-preview 链接查看您的页面的渲染效果。请务必保证您的页面能够按照您预期的方式渲染。 如果您在过程中有任何问题,欢迎留言。谢谢!

由于本 issue 并没有详细表达其诉求,无法进一步跟进,故暂时关闭此 issue。如果您有新的想法,欢迎 reopen 并补充您的修改意见。

有一个小建议,如果有空您可以考虑一下,就是是不是没有必要在介绍线段树二分的时候引入懒标记下传的部分。这好像会使得问题更为复杂,而且懒标记下传并非线段树二分的必要组成部分。

需要添加 .hpp 进入 check PR format 的检查列表中。

see https://github.com/OI-wiki/OI-wiki/pull/6412#discussion_r2267423920 分离模板代码不可避免地会带来展示代码的问题。基于目前的基础设施,格式手册中要求将所有辅助文件(包括头文件)一并合并展示到例题代码中。这样做可以方便读者一次性复制所有代码,进而阅读或测试。 但同时,它也会导致页面内容过于冗长。例如本 issue 提到的红黑树页面,在页面的同一位置出现了完整的头文件(400+ 行)和包含头文件的完整例题测试代码。考虑到后者只是前者的简单调用,这种重复造成了页面的冗长(尤其是 PDF 文件)。 对于更一般的情况,包含头文件容易造成阅读时失焦。如果一个页面出现多道递进的或者共用同一套头文件的代码,重复引入的头文件会使得读者无法迅速理解当前题目的核心内容;而且头文件的内容可能会分割对题目的解答的文字部分和它相应的核心代码,使得读者无法更方便地对照文字部分和核心代码部分。例如 CP Algo 的 [连分数](https://cp-algorithms.com/algebra/continued-fractions.html) 页面就在递进的例题中只展示核心代码(当然他们没有分离代码也就没有测试问题)。 鉴于目前使用头文件的情况并不多,所以这并 **不** 是一个亟需解决的问题。如果本项目中类似的实践越来越多,可以考虑引入自动展开代码的方案,允许页面在核心代码和完整代码之间切换。完整代码中还应包括 snippet 语法没有框进去的 I/O 部分等,或者支持线上测试(possibly related #3518)。 仅作备忘。

这个页面整体需要重写一遍,等月底吧。

这个直接在 .md 文件顶部补一个吧。原则上不存在不依附于某个页面的代码。所以算作页面的一部分就行了?

> > 这个直接在 .md 文件顶部补一个吧。原则上不存在不依附于某个页面的代码。所以算作页面的一部分就行了? > > 这个很明显要搞一个自动化的机制,人工的话太容易忘了 页面如果删除或者移动,还是需要人工转移 credits。代码重命名和删除的情况更多,最后还是依赖于人工转移页面的所有 credits,因为也很难区分这个页面的 credits 是不是代码部分的。 而且从这个角度看,判定哪些文件属于本页面也不容易。比如图片和头文件的代码某种意义也得包括进来。

研究了一下这个问题。目前看起来原因是 remark-details 插件在转换 markdown 为 mdast 后,没有处理 list 和 listItem 的 position 属性。 下面是一个例子。对下面的 `example.md`: ```md ## 性质 ???+ note "证明" - 引理 - 引理 证明:证毕。 - 引理 证明:证毕。 接下来我们证明。...

> 感谢 Debug,我的理解是一个上游问题?是否应该做一个最小复现反馈给上游 remark-details 也是 OI Wiki 维护的,严格来说这算上游吗?所以可能得看一下 @Enter-tainer 的意见,要不要修这个 bug。