太微中文论坛

@W1825 我感觉可以等一下MWS的发展。MWS发展起来了的话，十万个条目肯定是影响不大的。因为你可以把不同的东西放进不同的袋子里。

一年了，这个功能只能5.4.0版本中加入了。唉。

我感觉还是要这种偏娱乐向的内容能获得更多的受众。偏知识向的内容，不咋有人关注。只不过数据来源可能需要爬虫，但现在像豆瓣电影或其它什么平台对这方面限制挺多的。

我感觉可以制作一些公共资源库。不是实际的资源文件，而是提供一些像豆瓣电影这种的，更新一些主流的电影条目。里面有导演，演员一类的信息。其它人可以直接把它导入到自己的TiddlyWiki中。

• https://flibbles.github.io/tw5-relink/
• https://github.com/flibbles/tw5-relink

relink插件我是非常推荐安装的，几乎是每个TiddlyWiki的必备插件。在TiddlyWiki中，核心只有标题与标签两个字段会自动relink。但正文text字段并不会自动relink。换言之，如果没有这个插件，那么正文中的链接并不会自动更新，你需要手动更新，这太麻烦了。

而这个插件就可以自动辅助更新。其它条目也会一并更新。

而除了text字段外，还可以自定义字段。

比如我有一个条目A，里面记录了我从其它论坛用户学来的内容，里面有一个author字段，值为杰里米。表示这是杰里米提出来的一个解决方案。然后我也新建了一个杰里米的条目。

但有一天，我觉得应该用英文，所以我把杰里米这个条目改成了Jeremy，那么条目A中author的杰里米也会被自动修改成Jeremy。

而要实现上面的内容，只需要在relink设置中增加author为自定义字段即可。

如图所示，旁边的字段类型中，需要设置为title。

当然从这个字段类型中也可以看出，完全可以信赖其它字段。但我没有深入研究，就不说了。

我感觉只能手动更新链接。这确实比较麻烦。

感觉这个领域确实是需要AI来做一些辅助工作。

标题有点抽象，但可以解释一下。我最近在尝试一款新软件，Tangant，和大多数软件一样，里面有文档但全英文。我计划让AI翻译一下，然后把原文档和翻译后的文档都放进TiddlyWiki里。

目前我已经新建了一个TiddlyWiki，现在的问题是，我不想一个软件的文档就新建一个TiddlyWiki，因为我以后遇到其它软件的文档时，我也想保存在这个TiddlyWiki里。

但这就会有重名的问题。此其一。其二，里面的markdown也是有双链的，如何维持这个双链是比较麻烦的。其三是如何让中英文能够正确判断呢，比如有中文则跳转到中文链接中去。没有则显示英文链接。

目前我还没想到有什么特别好的解决办法。

@马萨伊尔

TiddlyWiki也可以看作是一个数据库，只是没有交互界面。需要自己重新写一个交互界面出来。自己写的容易定制化，想加什么功能就加什么，想怎么来就怎么来，其它笔记软件就不好说了。

https://talk.tiddlywiki.org/t/introducing-tw5-graph-tiddlymaps-spiritual-successor/13062

https://flibbles.github.io/tw5-graph/

以前TiddlyWiki有一个TiddlyMap插件，但这个插件原开发者很早就不维护了，导致后面TiddlyWiki更新时，经常会崩溃。也一直是Flibbles在进行维护更新，我记得他之前说，每次TiddlyWiki更新时 ，他就要来论坛抱怨几句，因为他又要再修一下TiddlyMap插件了。而当TW5-Graph插件正式推出 后，他应该不会再维护TiddlyMap插件了。

我简单试了一下，上面的文档写的挺全的。

Top-Down Tutorial
Bottom-Up Tutorial

搜索上面，有自下而上和自上而下两个方面的教程。我觉得比tiddlymap插件要好。至少有两个方面。一个方面是渲染引擎和前端独立出来了，虽然目前只有一个，但以后肯定还可以切换不同的引擎。另一个是微件更多了，可以自己写，非常方便。提供微件比单纯使用筛选器表达式要强大很多。更重要的是，没有tmap.id字段了。因为作者也是relink插件的作者，两个插件是完全集合的。这真的非常厉害。

目前我测试了一下性能极限。如果返回一个一千以上条目的，内容也能够正常渲染出来，但需要花更多的时间，大概要一分钟吧。另一个小问题是UI看起来还不够整洁。

后期再看有没有更新啥的，这个东西的好处就是，用户不需要额外写js代码，会用微件和筛选器就可以创作自己的视图。

https://tiddlywiki.com
https://bramchen.github.io/tw5-docs/zh-Hans/

上面两个网站都能正常加载，但我的博客网站好像就不行。也许是没有开权限？

---

好吧，要开权限。可以开本地的HTTP，就能加载进来。但如果是本地的话，就不需要这么麻烦了。还要再研究。

目前好像是有一个插件，$:/plugins/sq/ExternalContent，可以实现这方面的功能，但还没研究明白怎么用。

我预想的是，不直接把文件保存过来。而是加载这方面的内容。仓库本身只有一些tid文件之类的。

我自己有一个最近才开始维护的本地维基。然后通过这个本地维基来实现，一处更新，处处更新。目前这个TiddlyWiki是私有的。但我需要做一个公开的仓库，如何把这个内容引入进来呢？可以考虑把本地私有仓库设置为公开。但如何在启动服务时加载一个github仓库的一个文件夹中的内容呢？

教程或者技巧一类的文章，先发布在论坛上，后面逐渐更新到太微漫游文档和太微中文教程中去。

一篇文章分属两个部分，是考虑到可以提高知名度和传播。另外也是TiddlyWiki和markdown的两种不同形式。也许这样效果会好一点。

英文论坛那边有这么一个话题，引发了很多人讨论，很多人都分享了自己使用TiddlyWiki的方式。我就在这边分享一下。

有自己的笔记库，也有自己的信息库。信息库的意思是，存放自己任务，日志，收支一类的信息。也有自己的实验TiddlyWiki，不容易与其它TiddlyWiki产生冲突。最近我又搞了一个可以自动推送的阅读TiddlyWiki，把书籍内容导入进去就可以推送了。

当然还有一个跟社区相关的或者插件相关的。但一般是需要时才去启动。

其实TiddlyWiki可以看作是一个简单的数据库。最近我想把自己点过的外卖店给统计一下，看看经常吃什么，有些店还不错，有的比较贵，但容易忘。

还想做一个跟游戏相关的。我想把游戏里的中英文本提取出来放在一起。因为游戏通常有很多专有名词，已经有固定翻译了。但经常打mod的时候，mod没有翻译。而其实只要知道那些专有名词，理解起来就比较容易了。

还想做一个跟游戏mod相关的，把玩过的游戏mod记录下来。做成跟notion那种形式。但又觉得太麻烦了，有些mod还有前置mod，而发布网址也不固定。更主要是，有mod管理器了，就懒搞了。

https://talk.tiddlywiki.org/t/fully-automating-tiddlywiki-save-path-management/

英文论坛那边我补充了一个，把日志条目放到相应的文件夹中的方法。我就不转过来了。

效果如图。

要运行和测试下面内容，请确保对你的TiddlyWiki进行了多重备份工作。我不承担任何因文章造成了任何后果的责任。请一定一定一定要备份。

---

使用node.js的TiddlyWiki，里面有一个可以进行配置的条目。$:/config/FileSystemPaths，可以根据筛选器表达式，把不同的内容存放在不同的硬盘路径中。详细可查看自定义条目文件命名，但这个条目是一个配置条目，里面只能写筛选器表达式，不能写wikitext。如果只是简单的分类还好，但如果有上千个条目，或上万个条目，当我们想要在硬盘路径上有一个分类时，就需要采取其它方案了。为什么会进行分类呢？因为当windows系统面临一个文件夹里的上万个文件，很容易出现卡顿的情况。所以后期分类也许是有必要的。当然，如果超出了TiddlyWiki的承受极限和性能极限，那么更好的方式是采用多个TiddlyWiki来进行管理。

接下来进入正题，如何进行分类。这里我以一个最简单的示例来进行说明。首先你需要准备一些带有test字段的条目，并且这些条目有不同的字段值，且可以多准备一些条目，以看到更清楚的情况。另外，对于一些markdown文件也同样适用。

接着你需要新建一个条目，名称随意，这里我选择Filter Expression Generation，意思是用来产生筛选器表达式，里面的代码如下。

<$list filter="[has[test]get[test]unique[]enlist-input[]]" variable="testField">
<$set name="fieldValue" value=<<testField>> >
<$let
filterExpresision=`[test[$(fieldValue)$]addprefix[\]addprefix[$(fieldValue)$]]` >
<$text text=<<filterExpresision>> />
</$let>
</$set>
</$list>

保存后你可以看到一些跟下面很相似的筛选器表达式的内容。

[test[123]addprefix[\]addprefix[123]] [test[0023]addprefix[\]addprefix[0023]] [test[1111]addprefix[\]addprefix[1111]] [test[22]addprefix[\]addprefix[22]]

但这个内容没有维基化处理，并不能直接拿来使用。所以我们需要用到第二个条目，条目名同样随意，我这里使用Filter Expression Button，意思是通过按钮把上面筛选器表达式的内容存储下来。里面的代码如下。

<$wikify name="filterExpressionStorage" text={{Filter Expression Generation}} >
<$button>
<$let filterExpressionStorageValue={{{ [<filterExpressionStorage>search-replace:g:regexp[\n],[ ]search-replace:g:regexp[\s+],[ ]trim[]] }}} >
<$action-setfield $tiddler="Filter Expression Storage" $field="text" $value=<<filterExpressionStorageValue>> />
<$action-navigate $to="Filter Expression Storage"/>
Create or Update
</$let>
</$button>
</$wikify>

这里我稍微解释一下，里面用到了正则表达式进行筛选替换。但不用担心，这里并没有替换什么特别的内容，只是把多余的空行和空格删除了，并去除了开头和末尾的空格，让它看起来更美观。

ok，按下按钮，就会生成一个Filter Expression Storage条目，并把上面筛选器表达式的内容保存进去。接下来才需要对$:/config/FileSystemPaths进行处理，处理起来也非常简单，新建这个条目，如果有的话就编辑它。再把下面的内容保存进去，当然你可以有自己的其它内容。

[subfilter{Filter Expression Storage}addprefix[test/]]

这时你应该能明白了吧，subfilter会自动读取里面的值，运行里面每一个筛选器表达式，而里面的筛选器表达式又由按钮Filter Expression Button创建和保持更新。你不需要自己手动填写。而筛选器表达式的构建又来自于Filter Expression Generation。如果你是TiddlyWiki专业用户，那肯定可以举一反三，创造更多不同的用法。这里最关注的一点在于，上面的条目名不是绝对的，但你需要保持一致。你可以使用系统前缀，也可以使用自己自定义的，但一定要保持前缀。

但还没完。那些已经存在了的条目，并不会自动更新，除非你编辑他们。但你肯定不想手动去一个个编辑里面上千个条目。因而你可以使用插件$:/plugins/kookma/commander，打开$:/Commander条目，并输入一个合适的筛选器表达式。勾选Selective operation?，再点击Select all的按钮，然后取消勾选就可以了。这会导致筛选出来的条目被修改，但只是修改时间被修改了，内容并没有被修改。这是可以接受的。

这个时候，你再检查你的文件，你会发现他们被整齐地归类在不同的文件夹里了。

---

我知道，你还有疑问。但我也想到了。如果这个筛选器很复杂怎么办，很多怎么办，难道也要一个个输入吗？那太麻烦了。所以我们可以根据上面内容实现同样的筛选器表达式构建。

创建一个条目，名称任意，这里我使用Filter Expression Generation No Prefix，表示不加前缀，而不加前缀就可以获得正常的筛选器表达式了。

<$list filter="[has[test]get[test]unique[]enlist-input[]]" variable="testField">
<$set name="fieldValue" value=<<testField>> >
<$let
filterExpresision=`[test[$(fieldValue)$]]` >
<$text text=<<filterExpresision>> />
</$let>
</$set>
</$list>

接着，我们同样创建一个按钮条目，名称随意，这里我选择Filter Expression Button No Prefix，内容如下。

<$wikify name="filterExpressionStorage" text={{Filter Expression Generation No Prefix}} >
<$button>
<$let filterExpressionStorageValue={{{ [<filterExpressionStorage>search-replace:g:regexp[\n],[ ]search-replace:g:regexp[\s+],[ ]trim[]] }}} >
<$action-setfield $tiddler="Filter Expression Storage No Prefix" $field="text" $value=<<filterExpressionStorageValue>> />
Create or Update
</$let>
</$button>
</$wikify>

然后你就可以使用下面的筛选器表达式了。

[subfilter{Filter Expression Storage No Prefix}]

是不是非常简单。我在强调一下，在TiddlyWiki中，条目名并没有固定的方式，任何人都可以按他的喜好来进行不同的命名，但一定要保持名称一致。因为不一致是无法实现的。

---

最后，我必须再强调，一定一定一定要进行备份。在做任何测试之前，一定要进行备份。如果你没有git备份的话，很有可能造成无法挽回后果。我不承担上述内容所造成的后果的责任。请一定要确保进行了足够多的测试和足够多的备份工作，再进行操作。对于TiddlyWiki经验不足的用户，可以考虑发贴请求其它人的帮助。

在日常使用TiddlyWiki中，我们通常会安装一些插件来增加TiddlyWiki的功能和便利性。随着插件越来越多，页面上的按钮也会变得更多。那些不常用的按钮如果都放在更多按钮中，列表会非常长。因而我们可以通过子菜单来收纳按钮。

效果如图，日常使用是没问题的。其中的关键是快显机制中，有一个tc-popup-keep的类，可以让我们点击按钮之后保持不动。这就可以让我们查看子菜单和三级菜单。

https://bramchen.github.io/tw5-docs/zh-Hans/#PopupMechanism

目前不打算做成插件，因为做成插件挺麻烦的，还需要把内容都更新一下，写英文内容。特别是页面按钮，还需要用到我之前做的xnote插件。

但这是一个很不错的思路，因为还可以加入更多内容，可以有更强大的功能。

当然这种的还不能算是contextmenu，英文论坛那边有一个contextmenu，也是用wikitext写的，但我没咋看明白。

不过我自己还是喜欢wikitext。也推荐新建笔记用wikitext，因为包含了TiddlyWiki语法的markdown文件在其它软件里无法执行的。

可以看到，一般的TiddlyWiki语法都能支持。

那看样子可以对外宣传一个又旧又新的markdown笔记软件了。

我记得以前没有这么好来着，当时还有各种意外问题。