太微中文论坛

机

我最近在制作一个插件，我使用了一个字段tmo_dueDate，值为2025-06-19，格式一类的。但现在有一个问题，我想要根据这个字段值判断与当前日期的时间，如果是今天则展示为今天，如果是明天则提示成明天，如果是两个月后则显示为两个月后。

因为TiddlyWiki是按YYYY0MM0DD0hh0mm0ss0XXX的形式处理字符串的。社区目前有两个插件，一个是Date Picker plugin，一个是根据Projectify改编而来的Pikaday。两者都是基于pikaday库。前者功能强大，但年代久远，是好几年前的插件了。后者比较新，且kookma应该会一直维护。但后者也不好调整，只能限定字段为due，且存储的值也是一长串数字，类似于created一长串的值。因而我也不想采用。

因而大胡子搞了一个小工具可以进行转换。

TiddlyTools/Time/ParseDate

虽然也是两三年前的代码了，但我测试后可以在5.3.6版本中使用。

将上面的代码导入wiki后，要刷新一下加载js文件。

新建一个条目，名称随意，新建一个字段test，值为2025-06-19格式的。并把下面的代码放在正文中。

<$let today=<<now "YYYY-0MM-0DD">> format="[UTC]YYYY-0MM-0DD"
     oneday={{{ [[24]multiply[60]multiply[60]multiply[1000]] }}}
  yesterday={{{ [<today>parsedate[unixtime]subtract<oneday>parsedate:unixtime<format>] }}}
   tomorrow={{{ [<today>parsedate[unixtime]add<oneday>parsedate:unixtime<format>] }}}
	 tmoTime={{{ [{!!test}parsedate[YYYY0MM0DD0hh0mm0ss0XXX]format:relativedate[YYYY-0MM-0DD]] }}}>

<<yesterday>>

<<tomorrow>>

<%if [{!!test}match<yesterday>] %>
  昨天
<%elseif [{!!test}match<tomorrow>] %>
明天
<%elseif [{!!test}match<today>] %>
  今天
<%else%>
  <$text text=<<tmoTime>> />
<%endif%>
</$let>

可以看到，上面的条件判断可以分析出是今天，还是明天还是什么时候。

这非常方便，因为我们可以做更多的样式处理。

机

想要掌握更复杂的wikitext用法，可以研究研究官方核心里的系统条目和其他插件中的条目。可以看到他们是如何用wikitext构建一个组件的。会怎么使用list微件，又如何使用定义的变量。

机

组合一下就可以变成其他笔记软件中常见的编辑字段方式了。

组合的方式有机会直播的时候说一下吧。搞懂了就也很简单，两个方向，一个是通过页面上的按钮控制展示，展示编辑方式。另一个则是对编辑字段模板进行处理。

机

新建一个条目，名称任意，加上标签$:/tags/Macro ，把下面的内容放进去。

\whitespace trim

\procedure lingo-base() $:/language/EditTemplate/

\procedure tag-body-inner(colour,fallbackTarget,colourA,colourB,icon,tagField:"tags",tid)
<$wikify name="foregroundColor"
	text="""<$transclude $variable="contrastcolour"
		target=<<colour>>
		fallbackTarget=<<fallbackTarget>>
		colourA=<<colourA>>
		colourB=<<colourB>>/>
	"""
>
	<$let backgroundColor=<<colour>> >
		<span class="tc-tag-label tc-tag-list-item tc-small-gap-right"
			data-tag-title=<<currentTiddler>>
			style.color=<<foregroundColor>>
			style.fill=<<foregroundColor>>
			style.background-color=<<backgroundColor>>
		>
			<$transclude tiddler=<<icon>>/>
			<$view field="title" format="text"/>
			<$button class="tc-btn-invisible tc-remove-tag-button"
				style.fill=<<foregroundColor>>
			>
				<$action-listops $tiddler=<<tid>> $field=<<tagField>> $subfilter="-[{!!title}]"/>
				{{$:/core/images/close-button}}
			</$button>
		</span>
	</$let>
</$wikify>
\end

\procedure tag-body(colour,palette,icon,tagField:"tags",tid)
<$transclude $variable="tag-body-inner"
	colour=`$(colour)$`
	colourA={{{ [<palette>getindex[foreground]] }}}
	colourB={{{ [<palette>getindex[background]] }}}
	fallbackTarget={{{ [<palette>getindex[tag-background]] }}}
	icon=<<icon>>
	tagField=<<tagField>>
	tid=<<tid>>
/>
\end

\procedure edit-tags-template-x(tagField:"tags",tagListFilter,tid)
<div class="tc-edit-tags" >
	<$list filter="[<tid>get<tagField>enlist-input[]sort[title]]" storyview="pop">
		<$transclude $variable="tag-body"
			colour={{{ [<tid>] :cascade[all[shadows+tiddlers]tag[$:/tags/TiddlerColourFilter]!is[draft]get[text]] }}}
			palette={{$:/palette}}
			icon={{{ [<tid>] :cascade[all[shadows+tiddlers]tag[$:/tags/TiddlerIconFilter]!is[draft]get[text]] }}}
			tagField=<<tagField>>
			tagListFilter=<<tagListFilter>>
			tid=<<tid>>
		/>
	</$list>
	<$let tabIndex={{$:/config/EditTabIndex}} cancelPopups="yes">
		<$transclude $variable="tag-picker" tagField=<<tagField>> tagListFilter=<<tagListFilter>> tiddler=<<tid>> />
	</$let>
</div>
\end

然后你就得到了一个可以随时调用编辑字段的组件了。使用方式如下。

<$transclude
$variable="edit-tags-template-x"
tagField="123"
tagListFilter="[has[cluster]get[cluster]unique[]enlist-input[]unique[]]"
tid="0023"/>

修改0023这个条目的123字段，列表展示出来的内容是cluster字段的相关值。如下图所示。

下面是更详细的说明。

更改来自官方的$:/core/ui/EditTemplate/tags
修改了名称，改为edit-tags-template-x
更新了里面的宏使用方式，使用更现代的<$transclude $variable="" />
增加变量tid，允许更具体控制要修改的条目
tagField表示要修改的字段，默认是tags标签
tagListFilter则是下方列表内容，可以手动设置
上述是一个常见的示例，比如选择具有cluster字段的值
目前存在的问题有，编辑框内容无法修改
- 这是由底层的tag-picker宏控制的，修改起来很麻烦

使用用途应该很广泛，只要涉及到增加和修改属性，都可以用这个组件。且更适合用于需要存储多个类别的情况。

比如一款游戏，可能有多个类别，如果存储为标签，则很麻烦，因为可能造成标签失去控制。但存储在字段中，编辑起来又不方便，而用这个组件可以很好地解决。常用的也可以处理成编辑字段模板，如下图。

机

AI是免费的吗？还是申请api？

所见即所得插件有演示吗？想看看怎么样了。

机

@马萨伊尔我知道，但因为我常用的是客户端，很少用网页端。所以就不咋关注了。理论上还有一个redict的讨论区，但因为要注册才能查看，我就一直没关注。

机

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

机

@w6iyes 没有头绪肯定也不用去问。但对比一下Obsidian即可发现，关于Obsidian的内容，互联网上有太多太多了，不管是国内的还是国外的，还有很多人自发录制视频讲解，还有数不清的付费社区。但TiddlyWiki就没有这么幸运了。目前关于TiddlyWiki最丰富的信息来源就是英文论坛。

而且因为直接用浏览器访问，可以用沉浸式翻译插件知道在说什么。而TiddlyWiki的其他平台讨论都很少，discord比较丰富，但因为不能用浏览器翻译就没咋关注了。我用的discord客户端。

当然，我觉得TiddlyWiki论坛应该出一个精华帖子分类，但没看到有人这样做。不过倒是有一个技巧的分类，可以查看关于TiddlyWiki的一些使用技巧。

掌握一些技巧还是很重要的，然后就会发现，啊，原来还可以这样做，原来还可以那样做，那我改一改不就能实现另一种效果吗？大概是这样的心路历程。

notion的内容更多，使用笔记软件的用户群体，估计有60%都是notion，20%的Obsidian，其余的就给其他软件分了。

机

把TiddlyWiki玩一遍之后，最重要的就是组装，像搭积木一样，创建无限的可能。

但新手确实很难一下子学习这么多内容，特别是对于没有技术背景的用户来说。我自己也花了两三年的时间才觉得真正掌握了TiddlyWiki。

现在一般是两个方向推荐，推荐他把TiddlyWiki当成玩具去尝试，类似编程工具那样。另一个方向是让他把TiddlyWiki看成一个记事本，先写一些内容，再考虑之后的。比如写一些标签，字段，然后再考虑引用。

我也一直想写一个系统性的教程，但实在是不好写，难以下笔。因而一些阶段性的成果，要么放在论坛上，要么放在太微中文教程社区里。有时候会录一个视频分享，但现在很少了。

机

正因为TiddlyWiki的向后兼容性，所以你可能会发现一个问题几年前就被人回答了，并且之后一直有效。因此学习TiddlyWiki最好的办法，是根据自己的需求去论坛搜索。大概会有几种不同的解决办法，再考虑从他们的解决办法中扩展。

当然你重新提一个问题也可以，会有人提示你这个问题已经被解决过。

其实那边的论坛氛围真不错，基本上过一两天就有人回应了。而且大多数都是有经验的用户，很多都是TiddlyWiki的核心团队。

核心团队会有专门的卡片标识，估计在下一个版本中就能看到了。

机

@w6iyes 官方中文文档可能确实有一些不足。但目前并没有专门的团队去维护，而是一位台湾网友维护的，从2012年还是什么时候就开始了，维护了十年。我也看过一些其他版本的翻译，比如我记得之前有一个鱼无言的翻译，但好像止步于5.2.X版本了。之后再没有更新。

其实TiddlyWiki基本上没有删除过去的功能，绝大多数时候都是向后兼容的。

5.0.X版本是测试阶段，5.1.X版本是正式阶段，升级到5.2.X版本号是因为改变了数据存储结构。以前的数据存储结构好像是HTML格式，5.2.X之后换成了json格式。更新到5.3.X版本是，因为不再推荐使用marco形式，更推荐使用procedure等现代形式。能够保障代码的健壮性，具体解决了什么问题只能看论坛上的讨论了。

接下来要引入到5.4.X版本，从这个版本上来说，才会引入一些不兼容的更新。但绝大多数的功能都可以得到保留。

换言之，TiddlyWiki确实足够稳定，稳定到只使用某一个特定版本都可以一直用下去，直到浏览器被淘汰。但目前想象不出浏览器被淘汰的时代，想象不出有什么可以代替浏览器，感觉AI也无法代替浏览器。即使浏览器被淘汰了，也仍然有nodejs的版本可以使用。

因而如果能接受TiddlyWiki的话，那笔记确实是可以持续一辈子。

机

关键是掌握筛选器语法，不会筛选器语法就很难写自己的组件。其次是掌握基本的微件或者小工具的用法。

比如尝试写一个按钮，点击会新建标题为当前日期的条目。

再或者尝试写一个$list，展示筛选条目中的caption字段，如果没有则显示标题。

进一步掌握条件快捷语法。上面那个就需要用到条件快捷语法。

再之后就是使用$let进行自定义变量了。或者使用宏或者是进程。

学会使用宏和进程后就可以实现，一处打包，随处可用了。

再之后就是级联了。级联相当于模板。比如可以对[tag[123]]的标签条目正文只展示caption内容，如果没有caption则展示为标题。

大概过了这些，基本功能就掌握得差不多了。不管是看别人写的wikitext还是官方写的，都比较容易了。

最最重要的一点是，经常在论坛里提问。可以去英文论坛那边提问，通常都会有人解答的。当然现在也可以问一下deepwiki，这个还算是比较智能的。

机

哦不对，Tiddlywiki-NodeJS-Github-Template模板只有在太记更新后才会更新。也就是仓库里是最新版本的，但太记新建wiki时使用的并不是最新版本的，那就不好找bug了。

机

这个像是没打包。

但kara确实是只有两个文件，一个json，一个meta。

从上面的图片中可以看到是有一个json文件的，但不知道为什么被解析成了影子条目。在Tiddlywiki-NodeJS-Github-Template那边并没有这样的情况。我也只是新建之后，就是这样的，没有做特殊的处理。感觉像是CPL的解析错误，也有可能是TiddlyWiki的插件机制更新了。

机

@linonetwo 文件夹里并没有影子条目。所以我才觉得奇怪。而且应该不只这一个插件，之前好像也有几个插件是这样的情况。

机

我安装了$:/plugins/kookma/kara插件，但一搜索就出现下面所有的插件条目了。理论上来说不应该是这样的。

而且实际上也只有两个文件，而不是细碎的插件文件。总感觉像bug，但又说不上来是不是。以前好像也有类似的问题来着。

机

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

机

@dyp1121054136 具体是哪一个插件呢？不过我这个只是思路，并不是说具体的新建条目问题。

机

忘了补充一点，TiddlyWiki中标题的非法字符应该是[] | {} ，@和#应该是没问题的。如果要发布到社交平台，则可能需要去除，不然就会@了一个用户了。

机

知识类的笔记，我还是更相信自己整理的，而不是由AI提供。

——————

考虑这样一种笔记场景。有一本书叫《变形记》，是卡夫卡的一本短篇小说集。里面有一篇短篇小说，名字就是《变形记》。卡夫卡的影响力很大，在国内有好几个不同的译本。同时，《变形记》这篇小说，引起了很多人的关注，有相当多的论文和学术著作都会提到这篇小说，对里面的内容进行展开分析。

用AI总结的话来说，就是如何解决一个核心理念与众多实体之间的关系。在其他笔记软件中，特别是以文件夹为分类的笔记软件中，非常好解决，只要存放在不同的文件夹即可。因为引用的时候，会因为文件夹路径的不同，而指向具体的条目，不会出现错误引用。在TiddlyWiki中则不好处理。所以我们需要通过加前缀或者后缀来进行区分。

这里说一下，为什么不用论文的形式处理。比如把跟《变形记》相关的内容都整理和写在一个条目上，命名为变形记研究，这自然是一种不错的处理方式。但问题是，单个条目，特别是长条目，必须有相应的逻辑结构。这就导致了当后缀有新的研究成果时，很难再补充进去。每有一个新的研究成果，就需要调整一个特别长的条目，显然是不现实的，维护起来也很麻烦。

上述已经举出了一个例子，通过增加后缀的形式，变形记研究。但这里我不想使用后缀的形式。因为我已经有一个相对完整且合理的书籍结构了，书籍结构就是使用后缀的形式。而如果再继续使用后缀，在我的上下文背景中就会显示出这个条目。而这个是全局的，所以我并不想改变自己上下文背景中的设置。（但其实想改也是可以的，因为里面的代码最早还支持后缀匹配的形式，我删除了。因此还是只能说是个人习惯，而非某种强制性规定。）

变形记
- 变形记-info
- 变形记-note
- 变形记-copy
- 变形记-card
- 变形记-summary
- 变形记-topic
- 变形记-toc

在变形记-info的条目中，我可以维护这本书的所有字段，在变形记-note下，则可以维护所有关于这本书的笔记。通常来说，不是所有书籍都有多个译本，大多数都只有一个译本。而一些具有多个译本的书籍，则按先后阅读顺序来处理。下面就举例了一个类似的。通过加前缀的形式来表示区分。这里要说明一点的是，要按译者来处理，而不是按出版社处理，因为同一个出版社完全可以出版两个不同译者的作品。一些古籍也可以这样分类处理。

李译本-变形记
- 李译本-变形记-info

——————

要解决上面的问题，我们肯定要构建一个变形记原型或变形记理念，原型可能更常见于心理学或编程中的术语，而理念则是柏拉图使用的术语。AI给出了几种解决办法。

一种是使用::表示不同的类型。且是一种强类型的。比如Work::变形记和Book::变形记，这样就区分了原型和具体的实体。这种方式也许在其他笔记软件中合适，但在TiddlyWiki中，有一个问题，::会被转换成__的形式。换言之，Work::变形记在实际的文件夹中会被保存为Work__变形记，这是因为TiddlyWiki的保存机制处理的。类似的插件条目也会修改成下划线形式。不同的电脑系统中对文件名字符的限制不一样，所以就有这种保存机制来使得全平台统一。

另一种则是使用@字符，豆包和deepseek都推荐使用这种形式。@具有比较明显的语义性，表示提到某个问题，某个内容。例如@变形记。

还有一种比较普遍的，就是#，但更多的是推荐有作标签。例如#变形记。

当然这个前缀实际上可以替换成任何字符，比如§或者★。但要考虑到输入是否方便。另外，不建议使用emoji，因为文件名中包含emoji可能会有意料不到的问题。以前看到过一个帖子，说的是一个大学生的电脑运行软件经常出现问题，怎么排查都找不出问题，后来发现是他把用户名设置成了一个emoji。软件识别不出来，直接判定为非法字符报错了。

——————

最后一个问题，是否需要给每一个条目都这样设置呢？并不需要。只是在你觉得需要时，才需要。但假如说，没有一本书是叫尼采。那么我需要不需要构建一个@尼采的条目呢？我自己是觉得我需要去构建。因为尼采太重要了，很多20世纪哲学家的理论来源就是尼采。所以我需要去构建这样一个条目。但比如说罗纳德•博格，这个名字就不需要了。因为很少人知道他是研究德勒兹的专家。换言之是否需要这样处理都是根据实际情况来处理的，具体问题具体分析，而不是搞一刀切。

另一个问题是，一般来说，游戏不需要这样的特殊处理。比如艾尔登法环就是指艾尔登法环，没有第二个版本。不像《红楼梦》有多个版本一样。

————

以上。我发现很多说知识管理的文章，根本就没说到点子上。怪不得总是构建了一个又一个系统但没有真正使用上。

太微中文论坛

机杼

帖子