太微中文展示

@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版本中加入了。唉。

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

我感觉可以制作一些公共资源库。不是实际的资源文件，而是提供一些像豆瓣电影这种的，更新一些主流的电影条目。里面有导演，演员一类的信息。其它人可以直接把它导入到自己的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也可以看作是一个数据库，只是没有交互界面。需要自己重新写一个交互界面出来。自己写的容易定制化，想加什么功能就加什么，想怎么来就怎么来，其它笔记软件就不好说了。

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

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

Top-Down Tutorial
Bottom-Up Tutorial

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

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

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