太微中文论坛

另一种比较丰富的TiddlyWiki资源是各种各样的TiddlyWiki网站。这一点跟Obsidian和notion都不太一样。绝大多数笔记软件发布成网址的，都是一样的模型，可能主题不一样，但整体上的观感是一样的。而TiddlyWiki则不同，有些TiddlyWiki网站自定义程度非常高，几乎看不出来是由TiddlyWiki构建的，有很多组件，有些来自于别人的插件，有些是自己写的插件。我自己对TiddlyWiki的入门，更多的是从这些网站开始的。我看到了TiddlyWiki更多丰富的示例和可能性。以及我可以把这些示例很简单地拖放导入到自己的TiddlyWiki中。别人怎么写的，我几乎只要copy就可以了。而且也没有风险，至少我现在还没有看到要求付费使用的TiddlyWiki组件。

$:/plugins/linonetwo/title-caption 这个问题我之前遇到过，我就把它解包出来的文件都删了。
可能是CPL哪个版本有bug吧，安装的时候出错了把它给解压了，实际上不应该解压。

如果没看到解压出来的文件那就不用纠结了，应该没啥影响。

@机杼 $:/plugins/dyp/mulu，在https://dyp1121054136.github.io/dyp-plugins-library/中有示例，条目名叫“目录测试”

插件库的插件有介绍视频吗？感觉稳定下来了可以录一些介绍视频具体说明有什么功能。

所以我都是用 modern tiddlydev 来开发，避免被过去的其他东西影响。

Gatha 的作者也推荐说写插件的时候就用专门的生产wiki来做而不是在自己的个人wiki里做。

以上方法不知为什么失效了，自建了一个新的tiddlywiki中文版空白模板：

https://github.com/dyp1121054136/tw-online-template

示例：

https://dyp1121054136.github.io/tw-online-template/

不需要下载任何软件，写几条命令就能发布github pages了，而且会自动更新到最新版本的核心。

最好的解决办法是提供一个接口，可以直接判断出某一个条目来自于哪一个外部维基。但目前没有这个功能，估计只能等MWS插件来实现了。

因而目前的解决办法是对外部维基设置一个根条目，然后通过模板化语法去标记。如下面图片中，会对以Forge为根条目下的所有条目有一个标记，表示来自Forge。同时点开编辑时也会有一个提示。如果后期要公开成仓库的话，就需要设置一下里面的链接。目前没有这个打算就不管了。

b406afa1-2e54-4bd3-9176-6202ad3155c2-image.png

b0d8ad82-b23c-41cd-8233-7a37d6c6047b-image.png

52ef4582-ac98-4100-8021-a7e96a4e65d4-image.png

这里其实还有一个问题，TiddlyWiki有一个更好的机制，可以使用类似级联的操作方式给条目设置背景颜色。然后我发现虽然设置了，但css的优先级不是最高的，被其他条目覆盖了。而且这方面的示例又比较少，就没用。感觉还是应该再调整一下css。

$:/tags/ClassFilters/TiddlerTemplate

@linonetwo 我说的换行是那种代码块超过屏幕范围后的自动换行。我感觉那样会更方便查看，不然还需要滚动鼠标去查看完整的代码。

image.png

我觉得还是得靠新用户吧，刚开始玩折腾欲和分享欲会强一些。所以也不用为了宣传而去做特定模板，之后有各行各业新用户来了自然会有的。

主要还是去外部平台上分享短的介绍文章和视频吧，就像给太微引流最多的应该还是我知乎上那一篇。目前还没别的文章超越。

所见即所得编辑器就是这样的，两年前嵌入语法更新直接就没法用了，然后一直拖到现在。还是得让一些功能进入核心才比较稳。

还有我毕竟是字节出身，是根据平时用飞书的体验要要求太记的，也就要求了底层的太微开发平台。很多外国人反而就没啥要求，就闭门造车自己用得过去就行，经常说的句式就是「我觉得xxx够用了、我自己也不太需要xxx」。也有可能是外国人缺乏逐鹿中原的勇气，不敢和其它工具对撞一下，所以还是得我们中国人多来搅动一下局势。

@oeyoews 感觉这个没那么智能，可能给的材料和示例不够多。要是可以把你们写的插件库也放进去让他读取或许会好一些。

新语法front-matter、footnote、link-reference、image-reference、definition、内部链接、embed支持的效果

5942e73fb49e7341bb5ac0ef85251693.png

b3b124d0edb40c43fc34047384606b22.png

我大概明白怎么用了，简单概括如下

一个bags必须要有一个recipe，不然这个bags无法形成域名，也就无法编辑 一个recipe可以有多个bags，但至少有一个，不然无法构建 recipe中的bags有优先级。同样的标题条目，优先级高的被recipe使用，低的无效。 这样带来的一个好处是，你可以自己做一个定制化的wiki模板，然后维护这个模板 接着你在你的其他生产环境中使用这个模板，但有些功能你当前的生产环境你不需要，所以你可以直接修改你当前生产环境的内容，不会影响到你的bags条目 另一个更常见的好处是，当你更新你的模板时，其他使用该模板的recipe会直接更新，这样就不需要一直调整了

目前存在的问题

文档上说会跟用.tid展示内容不冲突，但没有具体说明如何处理 因为显示可以与git相结合 目前recipe和bag没有删除选项，可能是还没有做 目前插件也作为bags提供，这个方案有点不那么好。因为插件太多了，会有很多个bags。如果把CPL收录的插件提供过去，那有好几百个。上百个bags显示的就很糟糕了。 怎么与筛选器结合，这一点还没有说。目前来看，bags与筛选器无关，出现重名的条目，就按优秀级来处理。

可以期待实现的

个人知识库管理会更加高效 举例来说，我可以只在一个book-info的bags中更新书籍信息，而其他的什么都不管，当我需要查询书籍的信息时，我可以在book-info中查找，也可以直接在我的主知识库中查找。 以及上述实现的模板功能。我可以有一个template，里面包含了大量我自定义的功能，但没有打包成插件。而且这里可以是一个生产环境，我可以直接在这里测试。但有个可以预见的问题是，测试条目也会随之附带到main中，所以需要通过筛选器来结合处理。 减轻性能。虽然我不知道具体是怎么处理的，但可以预见的好处是，性能会得到极大的改善。当然这个可能需要测试。 多用户处理 比如论坛上很多个不同的wiki，估计就可以使用这种方式来处理展示了，但背后又涉及到git方面的内容，估计还是不行 可能需要服务器，这个有点麻烦。因为文档中举了一个老师的例子，老师可以把他的教学资料放在一个bags中，而学生可以每个人都有一个自己的bags，可以提交作业。然后老师查看且修改。理论上都没有问题，最大的问题在于，是老师去部署这个服务器还是学校，学校真的会这样做吗？ 这个肯定是学校部署的，老师估计是类似跟用学习通一样。算了，这方面还是不过多讨论了。

感觉等技术成熟了，太记应该可以把这个放进去，从而构建更强大的TiddlyWiki。

确实，我把list想得太抽象了。

后来我发现，即使我要判断，但因为我的节点丸和根目录是放在一起的，所以实际上我只要判断节点丸就可以了。并不需要判断那么多根目录。因为节点丸也足矣构成上下文内容。

布局主要是为了全屏还有隔离CSS样式，也没必要所有功能都用布局来做。

应该是靠生成多个文件夹，例如 https://tiddlywiki.com/dev/ 其实访问的是 https://tiddlywiki.com/dev/index.html ，默认访问的是 https://tiddlywiki.com/index.html

所以就是在 Github Actions 里生成多个文件夹的结构再部署就行了吧。我猜猜是这样，不过既然 https://tiddlywiki.com/ 没被墙，那应该不是 Github Pages 部署的吧？不过在 Actions 里部署，然后推到 netlify 上应该也可以国内访问。

css还好，主要是wikitext，写复杂了就看得麻烦了。也因为代码总是修改，并不是那种一下子就写好的，所以才会不好调整。

参考 cherry studio 做一个，不过还是以知识库为中心

9a355923-e936-446c-b8b2-237364df3e65-图片.png

log 出来的宏只是字符串，只占用很小的内存。只有执行的时候才会解析字符串，才会消耗 CPU，不过也不多。