你是使用直接生成密钥还是使用密码生成密钥的？

错误的，列表项属于容器块，根据外框来看，这个列表项的内容就是超级块。

你的超级生成方法不太对。

更简单的方法是想办法从硬盘中获取密钥。

其他电脑没有密钥吗？

只要有一处记录了，那就还有希望。

首先，思源本体是纯本地应用，开发者没有能力查看你的笔记内容。如果不信可以自己看源代码，或者相信其他看了源代码没说话的人

其次，思源的云端同步功能是加密上传的，对于思源官方或第三方的 webdev、s3 储存来说，都看不到你的笔记内容，只能知道你的总体笔记大小，谈何对你的敏感内容进行和谐？

最后，思源只有两种云端的付费服务存在和谐可能，一个是微信的收集箱服务，一个是用于发布文章到网上时图片的临时图床服务。这两个都是没有加密的，前者思源不查微信官方也看得到，后者一般来说思源不会无聊去翻看，而且就算看了最多也就是删除服务器的文件，对你本地的图片毫无影响。

建议校验一下两个版本思源 2.7.3 的 md5 码，确定一下是不是同一个文件。

使用这个功能。

额，抱歉，我发帖子的时候显然忘记把代码贴上去了……不过我又更新了一次了。

思源开了两个端口，一个固定端口，一个随机端口。6806 是默认的固定端口，如果被占用了，自动加 1，避免打不开。

这个思维导图不是思源本体提供的功能，请找主题的制作者反馈。

保存为命名查询，然后使用命名查询。

查看命名查询

有时用，作为默认主题的替代，因为基本只有外观的改变，没有太大功能增加，比较流畅。

感觉还是挺不错的。

不能，思源必须通过导入的方式把 md 转化为解析过的 json 文件才能加载。

一个更简单的 bug 测试样例：

在最新版本的 dev 可稳定复现

分配到下周的可以写，但是实现分配到下一周每一天可见、或者分配到下一周第一天可见都比较难实现。

所以目前简单的实现只能做到分配到 7 天后的那一天可以查询到。

* [ ] .action{now |date_modify "168h"| date "2006-01-02"}

我只能部分的赞同你的观点，这确实是优势，但是只有这个是不足够的。

内容聚合使用这么“原始”的方法确实不行，不是它原始——我称之为自由，而是因为大部分需求没那么高的用户不需要这么多的可自定义，据我观察，大部分人只需要查询关键字的内容聚合就足够了。

所以我建议能支持使用关键字和思源高级语法的内容聚合，或者能通过以上两个自动生成 sql 的功能。

查询分配到今日的任务，配合模板使用

.action{$today := now | date "2006-01-02"}
{{SELECT * FROM blocks WHERE markdown LIKE '%[ ]%' AND  markdown LIKE '%.action{$today}%' AND subtype = 't' AND type = 'i'}}

可查询类似：

• 2023-01-12 的任务

你有三种选择：

1. 
   点击这里，会有删除按钮。

2. 

   旁边文档树的这个功能

3. 

   设置-文档树的这个功能

我一般使用第二种，看你的想法了。

没太理解是什么情况……反正我确实是使用了教育优惠的。你是按照步骤来的吗？

我的测试可以。

有可能是 bug。

1. 块的 attributes 目前好像只有书签、命名、别名和备注，我觉得还是很简单的。
2. query languages 就是 sql，这并不简单，不是思源的文档能讲清楚的。但是在思源里面使用还是比较简单的，虽然我觉得能支持使用关键词、高级查询、正则表达式生成 sql 会更好
3. mention 在双链笔记里算是很泛滥的概念，虽然我个人比较少用。
4. superblock……看了下文档，确实，虽然挺好理解的，但是文档里没说确实费解。
5. ctrl f 弹出来的就是当前笔记的搜索，因为思源的当前笔记搜索是使用全局搜索加上 当前文档限制 实现的。我个人挺欣赏这种解决方案的，简化的不错。

1. 这个集市里已经有模板实现了
2. 没懂你的意思

已知 bug，开发版已修复

有没有使用数据历史回滚？

原来如此，目前标题块制卡会直接把下面的内容也显示出来。这是一个 bug 吗？

@88250

emmm，这是把二级标题转化为超级块了吗？但是好像也不是，超级块是默认隐藏第一行以外内容的。

是怎么实现使用非超级块添加多个块的卡片？

已知 bug，开发版已修复，正式版下个版本修复。

请使用这个功能：

关于闪卡机制的进一步思考

在之前对于闪卡机制的讨论中，我总结到我不支持文档树卡包的原因是，这样不公平。文档树卡包的机制对于习惯于使用文档树管理笔记的用户来说可谓得心应手，但却相当于牺牲使用其他管理笔记方式的用户，因为他们将不得不使用文档树才能管理卡包。

经过进一步的思考，我认为论点还能在加一个，那就是不值得。

首先是不公平。

• 楼主后来举出了很多例子来论证文档树卡包对 daily note 的支持程度，但是就楼主举的例子而言，这只能说 RemNote 对于 daily note 支持尚可，与思源的卡包机制不相上下。
• 但 daily note 只是众多记笔记方式中的一种，过去的、未来的笔记方式数不胜数。
• RemNote 是内置对 daily note 的支持的，但在这种情况下，RemNote 对 daily note 的支持尚不能胜过卡包机制，又怎么能让人对于这种明显特化于结构化知识库的机制保有信心？
• 也许对于大多数的记笔记方式方式而言，卡包机制并不是最好的制卡方式，但它绝对是一视同仁、最不坏的方式。哪怕是文档树的形式，卡包机制配合多选也是差强人意的。

接着是不值得。

• RemNote 的文档树卡包与思源的卡包机制，其实两边的制卡这一步流程的总体繁琐程度都差不多。

  • RemNote 需要预先建立层层的文档树，才能找到录入卡片的位置。以后每次录入知识，都要经历一遍找位置的过程。
  • 思源需要每一次都选择卡片，经过 3 步后将卡片录入卡包。

• RemNote 前期累一点，后期简单一点，思源的卡包机制则是从头到尾都很平稳，一样的压力。你可以崇尚一劳永逸，也可以赞同平稳无压记录。但是，在这一步，是很难辨出胜负的。

• RemNote 的最大优势，在我看来，就是在制成卡片后，能实现卡包的继承机制，也就是

  一张卡片，不仅属于当前文档的卡包，同时属于它的父文档的卡包以及祖先文档的卡包

  但是，有没有可能，这种特性，只需要对于思源现在的卡包机制进行改进，让它能支持嵌套卡包就能实现呢？

  • 同样是改进，嵌套卡包只需要对相当于官方插件的卡包机制进行少许改造，就能实现同样的功能，而且这种改进完全是帕累托最优的，不会有人因这个改进而体验改变甚至变差。

  • 而如果是实现文档树卡包，那就相当于：

    • 废掉目前的卡包机制
    • 同时还需要对思源的本体动手脚，实现类似于 RemNote 的一堆特性，如多选嵌入
    • 还要实现因为软件差异、不知道 RemNote 有没有实现的特性，如页面克隆

    否则不要说其他笔记方式了，连 daily note 都要深受影响。这过程必然伴随一大堆的 bug，漫长的升级过程，长期对于其他笔记用户相当于废掉的闪卡机制，而换来的只是对他们而言并不太可能显著优于目前机制的文档树卡包。

综上所述，基于不公平和不值得两个点，我认为不应该废除目前的卡包机制，有一定精力的情况下，建议开发者加入快捷键制卡和默认卡包机制。在精力足够的情况下，建议开发者可以尝试加入嵌套卡包特性。而在目前卡包改进走到尽头后，再考虑文档树卡包机制。

在集市的主题简单点的只是换了颜色，但复杂点的都会对思源的默认界面进行修改。