太微中文展示

链接打不开

@king0billy

那肯定不是。TiddlyWiki与Obsidian各有所长，各有不同的使用场景，还是要看不同的需求。我提出这个方案只是为了满足在TiddlyWiki里能正常加载Obsidian编辑的MD文件。因为Obsidian的流行，导致很多MD编辑器也是使用YAML格式的。

TiddlyWiki擅长的是筛选器和筛选器带来的微件，以及由微件带来的自定义用户界面。这些都是Obsidian或其它任何软件无法实现的。至少我搜寻过太多软件很少能做到这一点。尤其是深度结合HTML和css的，大多数还要写lua脚本，然后实现一个原生但简陋的功能。比如sliver bullet。

我最近有打算在五一假期或者什么时候一个大长假的时候，重新设计自己的TiddlyWiki界面。一个功能繁杂但也许能满足我需要的。

再比如，我之前应该也有在论坛发过，那种借助太记可以实现同一个wiki，多个不同展示界面同时访问的那种功能。这也是Obsidian或其它软件无法实现的。他们有标签页，但其实两者不是一个东西。

现在上班了，时间不多，但有时候还是会用周末写一下。比如这里标题下面那些按钮就是我自己写的。

点击 可以切换不同的展示方式，且有另一个背景颜色提示。

---

这里还要再说回来，如果会JS，那TiddlyWiki也好，Obsidian也好，两者都有很大的扩展空间，甚至Obsidian会更大一点。但关键是，什么是你需要的。每个人需求不一样，对应场景不一样。对笔记软件的看法也不一样。

比如我现在迫切想用上MWS，因为我始终担心nodejs版本的TiddlyWiki存储性能不够。不足以支撑未来庞大的数据量。

我在英文论坛那边提了一下，让杰里米在5.4.0版本发布一周后做个直播，分享里面的新功能和一些高级用户使用5.4.0新功能的改变，或者插件有什么变化等内容。但杰里米没回我。

因而我打算在五一假期时，找个时间来聊一下TiddlyWiki。虽然我也有快一年时间没研究TiddlyWiki了。但之前研究的内容也可以分享出来。

感觉这种大版本更新应该要多多发视频介绍。remnote每更新一次，就发邮件，一个大点的版本更新就发youtube视频。咱们TiddlyWiki更新的视频太少了。

当然现在都搞AI笔记软件去了，尤其是还有人说MD是AI的母语，我看了真的觉得好笑。

@w6iyes 现在基本上不用define 了，基本上改用procedure了

@king0billy

https://talk.tiddlywiki.org/t/tiddlywiki-v5-4-0-will-be-released-on-20th-april-2026/

就直接上英文论坛看就可以了。

@s793016 现在要发布了，就在4月20日。

@W1825 可以正常你复制一个，把里面的created 和modified 对调一下就好了。

还有个办法，就是自己写一个button按钮，里面的action-setfield，可以设置属性$timestamp 为no，但奇怪的是这个属性并不是所有微件都支持，还是不够统一。

简要写一下我的挂载路径。

tiddlers\
tiddlers\TW-Obsidian
tiddlers\TW-Obsidian\tiddlywiki.files
TW-Obsidian
TW-Obsidian\.obsidian
TW-Obsidian\ROOT
TW-Obsidian\ROOT\测试.md
TW-Obsidian\ROOT\测试.md.meta

简单来说，即把Obsidian编辑存在的文件夹放在tiddlers同级的外层，而不放在里面。不放在里面是因为会加载像.obsidian这个带有插件等其它文件性质的文件夹。而后面把所有文件全都放进ROOT文件夹中也是如此。因为我们不想把.obsidian也挂载进去。

tiddlywiki.files 文件本质上是一个纯文本的json文件。我是按上面的路径进行配置的，并增加了isEditableFile属性，使得可以在TiddlyWiki中进行编辑md文件，并修改原文件。不然的话，在TiddlyWiki里编辑过后会在tiddlers文件夹中生成同名文件。

{
  "directories": [
    {
      "path": "../../TW-Obsidian/ROOT",
      "isEditableFile": true
    }
  ]
}

最后记得在.gitignore文件中新增一行，避免对这些插件内容进行跟踪，当然如果你想使用git进行多端同步的话，也可以不排除。

# 排除掉Obsidian相关的插件设置
TW-Obsidian/.obsidian/

我是重度TiddlyWiki用户，也几次想尝试emacs，奇怪的是我感觉自己跟emacs相性不合，怎么都玩不下去。但多少也可以比较一下。

emacs本质上是编辑器，org mode是里面用来编辑org文件的插件。org是一种大纲式的标记语言。我在网上有看过，有的人写起来非常丝滑。

TiddlyWiki则是网页式的单页面应用，其依赖于浏览器。

两者的共同点在于，都具有高度的自定义性，可编程性。不一样的是，emacs是真的在写编程代码，而TiddlyWiki还包裹了一层wikitext，因而代码写起来相对简单很多。甚至不需要js技能就可以使用。而emacs，我感觉不会lisp应该是用不明白的。这也就导致两者都有一个共同点，学习难度大。

但好在两者的社区都比较繁荣，TiddlyWiki的社区也很不错，经常在论坛上问问题能立即得到回答。

org mode或者后面的org roam，有个好处是，其明文存储，但在编辑时会进行数据库构建。这就使得不管有多少个org文件，多大的org文件，写在何处的属性，都能立即展示出来。比如做任务管理，全部列举出来。

这一点TiddlyWiki还做不到。TiddlyWiki是明文存储，但没办法进行数据库构建，因而在后期笔记数量达到一定程度时，确实会出现性能下降，编辑缓慢。但一来这个量级要非常大，至少要几万条笔记（不包含图像等媒体文件的话），二来这个问题也是可以解决的，且有多种解决方案。可以有MWS，也可以看看我刚提出来的，用Obsidian编辑md文件然后在TiddlyWiki里展示的方案。

TiddlyWiki与emacs的org mode区别还在于，TiddlyWiki更倾向于把文件拆分成多个条目，而org mode则无所谓。在TiddlyWiki里，一个条目或者说笔记如果有两万字，编辑起来能明显感觉到有些卡顿。

TiddlyWiki可以在多处运行，甚至可以放在u盘里。emacs能不能这样做我就不清楚了。TiddlyWiki可以搭建博客，发布文章，emacs应该也有类似的插件可以实现这种功能。

在我看来，TiddlyWiki更像是一个前台，更像是一个展示的空间。我可以在这个空间里随意构建我想要的内容。TiddlyWiki更像是独一无二的具有自指性质，自我更新的软件，其它软件则很难做到。emacs的生态如今下放到Obsidian里去了，因为Obsidian使用md文件且插件丰富。再有一部分就下放到vscode里去了，毕竟不用自己配置emacs了。还有一部分转移到roam或者tana这种专门的大纲笔记软件。

当然TiddlyWiki也有用户流失。但不像emacs用户有好的归属。

感觉写得有点混乱，我对emacs了解实在太少。

最近我重新搞了下博客，用Obsidian写MD文件，用hugo搭建。后面我想到，为什么不能用Obsidian编辑md，然后转换成TiddlyWiki可识别的模式呢？

TiddlyWiki是支持md文件的，但TiddlyWiki与市场上大多数支持md的笔记软件不太一样，TiddlyWiki是把属性保存在meta文件中的。类似于下面这种形式。meta文件的内容就是常见的键值对，属性值的内容。而Obsidian则是把属性值存放在MD文件自身的YAML格式上。这一点是写在Obsidian核心里的。而为了绕过这一点，我的思路也很简单，当插件检测到用户正在使用Obsidian编辑md文件时，把meta里的内容复制到md文件上，而当用户编辑完成时，则把编辑之后的yaml内容移动到meta文件中并在md文件里删除yaml内容。因为每次只要面对一个或少数几个md文件，性能上应该没什么压力。

测试.md
测试.md.meta

---
tags: TiddlyWiki
---

目前已开源，只需要到仓库里，看一下安装方式就好。整个插件完全是由Grok写的，想改代码可以看一下自己改，

展示

好处

这样就可以实现，TiddlyWiki和Obsidian，我全都要。在Obsidian里，完全可以和正常的Obsidian一样进行编辑安装插件。但注意无法使用像dataview这种插件，因为其是读取yaml格式的。Obsidian负责编辑文件，而TiddlyWiki负责数据库和前端展示。因为TiddlyWiki的筛选器语法真的比dataview要简单很多，且扩展性更强。

同理，这个思路还可以用在其它软件上。如果你会使用Emacs，也可以进行相应的操作，无非是把md文件换成org文件，在代码层面应该是不难做到这种事情的。emacs的org-roam自带一个数据库加载，在编辑时加载会非常方便。TiddlyWiki在这里重点需要负责的内容只有前端展示。

那为什么要搞得这么复杂呢？

也很简单，因为如果不依赖这些软件，完全自己去写代码和数据的话，工作量会非常大。对于非程序员群体来说很不友好。上述方案至少还能跑得通。

其次是可以方便在TiddlyWiki里对接AI功能。借助Obsidian的生态，AI正常在Obsidian里生产文章，一编辑就保存到TiddlyWiki的数据库了。非常方便，也不用担心TiddlyWiki一直没有AI功能而搞不定了。

注意事项

• Obsidian中不支持纯数字标签，但TiddlyWiki是支持，因而在使用Obsidian编辑TiddlyWiki的md文件时，应注意这一点。
  • 这个也是写在Obsidian核心里的，很难绕过。
• TiddlyWiki不允许重名，而Obsidian允许在不同的文件夹下重名。因而插件有检测机制，检测在当前Obsidian库中存在重名文件时，便会出现弹窗提醒更改。
  • 但同样有个问题。我使用Obsidian的库是挂载在tiddlers文件夹外部，插件无法检测到tiddlers内部的文件。需要注意。
• Obsidian会实时检测到MD文件的修改。且可以在TiddlyWiki中修改和编辑MD文件。但反过来则不行，在Obsidian进行编辑后的MD文件，TiddlyWiki需要重启才能读取到。
  • 太记最近好像有做检测外部修改文件然后重启的功能，但目前还是实验性的。
• 插件有进行转换的功能，但好像没写好。
  • 技术好的可以再加功能。直接提pr或者联系我开仓库权限，或者写好了发个评论我去下载。

文档中说是会增加一个空格然后递增数字，但明显实现不了。

从上面两个截图可以看出没有实现这个功能。

因而保险起见，还是不要_作为标题字符。

重新启动服务后，另外一条笔记就没了。

先保存在这里，后面有时间再去提issue。

这里最大的问题是，TiddlyWiki会把/转换成_，但同时在标题里并没有进行这样处理。

这就造成了在TiddlyWiki中存在上述图片中两个合格的写法，而文件保存只会保存一个。当下次再进行刷新保存的时候，就会变成123这个内容了。

是123还是456，完全取决于上述两个条目谁是最后编辑的，最后编辑的会覆盖之前编辑的内容。

类似于这种图像也可以放进一个tabs里。这样展示起来也很方便，想看就点击查看。不想看就关闭了。

---

最近对TiddlyWiki又有了一点想法。

可以做类似于trilium旧版的这种tabs功能。相当于在笔记下面有一排tabs，点击可以展开相应的内容，默认是不展示的。再点击可以关闭。

而且这样还可以放一排按钮进行，随时可以进行控制展示。

当然trilium新版布局不是这样的。新版布局更接近于notion那种风格。

@Neonity

可以啊，且非常适合做这种事情。

但如果要突显出TiddlyWiki的特点，可能还得花点心思。

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

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

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