Imple Lee

feature suggestion: add a notation for callbacks that expects the user to implement

8

There exist some callbacks in the [LÖVE](https://love2d.org) framework, like [`love.conf`](https://love2d.org/wiki/Config_Files), [`love.draw`](https://love2d.org/wiki/love.draw) and [some others](https://love2d.org/wiki/love#Callbacks), and there is currently no way in EmmyLua to note that they are callbacks rather than...

如何处理数学公式中的多字母变量？

5

按惯例，数学公式中每个变量都是单字母的，而多个字母相继出现表示它们相乘。多字母变量事实上完全不能fit到这个惯例中。 但另一方面，编程中的变量都是多字母的，进而在推导相关数学公式时，写这些变量在程序中的多字母名字看上去更自然也更统一。因此，从与程序一致的角度来说，多字母变量是更好的。 现有的实践中，多字母变量在本wiki是常见现象。例如，[字符串基础](https://oi-wiki.org/string/basic/)页面中就出现了许多多字母变量。它们完全是按照多个变量相乘的格式被format的，我的感觉是它们比较难看。 另一个可能的选项是使用等宽字体`\mathtt`来显示它们。有一些已有的实践（如 #4374 和 #3344），但毕竟也没有形成完整的传统，而且在公式中出现等宽的变量可能有些奇特……

[内容有误] 替罪羊树的实现中重构过于频繁

3

### 请选择： - [ ] 我正在着手修复这个问题 ### 我正在访问这个页面 https://oi-wiki.org/ds/sgt/ ### 我发现页面有这样的问题 页面上的替罪羊树的实现中，插入可能导致多次重构，但实际上替罪羊树在每次插入时只需要一次重构。多次重构可能导致复杂度错误以及性能降低。更具体地，插入时应当需要且仅需要重构**任意一个**不平衡的祖先节点。[1] 另外，该实现中删除节点也可能导致多次重构，这可能是不必要的（至少肯定可以只重构最大的子树）。但由于原论文中的删除的实现方式与该实现的实现方式不同，我不能断言这一定有误。原论文的实现方式为直接删除对应节点但不检查每棵子树的平衡条件，而是在全树的大小失衡时直接重构整棵树。 另：替罪羊树的名称就是因为它会推举**这一个**不平衡的节点作为“替罪羊”。 [1] Galperin, Igal, and Ronald L. Rivest. "Scapegoat Trees." In SODA, vol. 93, pp. 165-174. 1993.

现今plum只能支持clone GitHub上的git repo，即`scripts/fetch-package.sh`所示： https://github.com/rime/plum/blob/6f502ff6fa87789847fa18200415318e705bffa4/scripts/fetch-package.sh#L25-L25 但用户也可能有使用非GitHub的package的需求，比如在我的use case中，我想要略微调整我使用的双拼输入法的键位排布，做一个新的方案，但我不想上传到GitHub，而仅仅想供我个人使用。但plum并不支持clone非GitHub的repo，致使我不得不把我本地的repo上传GitHub。如果plum支持我混用本地的repo，就能大幅提高我的使用体验。 按我个人的猜想，会去安装客制化输入方案的rime用户中自行调整输入方案的用户可能也不在少数，支持非GitHub的（尤其是本地的）package也能很好地支持package开发途中的体验。因此我认为该feature会比较有用，值得支持。

fix #1102

Of course, full text of licenses should be included. Maybe we can take [love2d's license.txt](https://github.com/love2d/love/blob/main/license.txt) as a reference. Proposed licenses to be included: - techmino: LGPL 3.0 - [cold clear](https://github.com/26F-Studio/cold-clear/)...

infinite height toggle should not be added in the Infinite and Infinite Dig modes

26

Infinite height toggle was introduced in #961 as requested by #959 , but introducing infinite height toggle in the infinite mode actually breaks the mode's functionality positioning, i.e. the prototype...

Cannot place O mino into certain places that need softdrop in finesse lock mode

2

https://github.com/26F-Studio/Techmino/assets/80144331/307dc6fa-f957-4cd4-a9da-a68bb51b6f14 ~Actually I am not certain whether this is only shown with the touch screen...~ This is also present on other platforms.