有个切换主题的插件，你可以在市场里面搜索一些。

有一个‘中键小窗’的插件，可以点一下直接唤出一个全局的小窗口。

ISOWeek 定义如此：一年中的第一周是包含该年第一个周四的那一周。这意味着第一周至少有四天在新的一年中。

这种属于特殊情况，遇到了就手动改一下吧。

自己调用 addecharts 都是支持的。

折线、柱状图、tree、graph 是我为了方便和思源的数据结构对接特别封装的。你完全可以不管这些，自己构建 echarts 的 option。

    let results = Query.wrapit([]);
    //按照 root_id 字段分组
    Query.wrapit(documents).groupby('年月', (date, blocks) => {
        // 累加 blocks 中的时间
        let sum = blocks.reduce((acc, cur) => acc + cur.时间, 0);
        results.push({
            年月: date,
            时间: sum
        });
        // dv.addmd(`- ${date}, 总计阅读时间：${sum}`);
    });
    dv.addeline(results.pick('年月'), results.pick('时间'));

不清楚你说的统计阅读时间是啥，我就按照我理解中的写了一下。

在没有属性标识，单纯靠关键字来查询文档还是麻烦了一点，我后面想想看能不能加一些这方面的工具函数。

//!js
const contentReg = async (reg) => {
    return Query.sql(`select * from blocks where content REGEXP '^${reg}$'`);
}

const extractNumber = (blocks, prefix) => {
    return blocks.map(block => {
        const match = block.content.match(new RegExp(`${prefix}：([0-9]+(?:\\.[0-9]+)?)`));
        return match ? { ...block, number: parseFloat(match[1]) } : null;
    }).filter(Boolean);
};

const query = async () => {
    // 创建数据视图对象
    let dv = Query.DataView(protyle, item, top);

    // 1. 构建 SQL 提取 content
    let with年月 = await contentReg('年月：[0-9]+(\.[0-9]+)?');
    let with时间 = await contentReg('时间：[0-9]+(\.[0-9]+)?');

    with年月 = extractNumber(with年月, '年月');
    with时间 = extractNumber(with时间, '时间');

    let 年月 = Query.utils.asMap(with年月, 'root_id');
    let 时间 = Query.utils.asMap(with时间, 'root_id');
  
    //按照相同的 root_id 字段将 with年月 和 with时间合并成一个大 list
    let documents = [];
    Object.keys(年月).forEach(root_id => {
        // 文档，年月数字，时间数字
        documents.push({
            root_id,
            年月: 年月[root_id]?.number ?? '无法找到对应年月',
            时间: 时间[root_id]?.number ?? 0
        })
    });

    let results = [];
    //按照年月来分组，累加计算各个文档中的「时间」
    Query.wrapit(documents).groupby('年月', (date, blocks) => {
        // 累加 blocks 中的时间
        let sum = blocks.reduce((acc, cur) => acc + cur.时间, 0);
        // results.push({
        //     年月: date,
        //     时间: sum
        // });
        dv.addmd(`- ${date}, 总计阅读时间：${sum}`);
    });
    dv.render();
}
return query();

这个实现的效果是，累加每个「年月」的阅读「时间」字段，然后汇总显示。
具体的 js 代码看不懂可以喂给 GPT 解读一下。

看着似乎是 Knote 插件提供的功能？

你可以看一下块的自定义属性里面是不是有特别的标识。如果有就查询自定义块属性。

公司网络严格吗，也许可以用手机伺服来替代本机安装思源。

笔记本存在的最大意义是它可以被「关闭」——这意味着在运行的时候不纳入索引存储，降低内存开销。

比如你记录了 1 个 GB 的笔记，但是里面有 300MB 的内容是老黄历，只是归档放在那里，大概率也不会访问。

这种情况下，如果这 300MB 的笔记刚好都放在一个笔记本里面，那就可以把这个笔记本关掉；这样思源在运行的时候就只会索引剩下 700MB 的内容，降低运行时的存储和计算开销。

这样？

新上的 Query&View 插件里面有这个案例，你可以到 example 里面找找。

「快速添加块属性」插件，配置一下 @style 规则

QueryView 插件.sy.zip

.action{$week := add (mod (div ((toDate "2006-01-02" "2050-03-13").Sub now).Hours 24) 7) 1}
.action{$today := last (slice (list "星期六" "星期五" "星期四" "星期三" "星期二" "星期一" "星期天") 0 $week )}
.action{$datestr := now | date "2006-01-02"}
.action{$datestr_sy := now | date "20060102"}

## .action{$datestr} .action{$today}

主要是技术上不一定方便实现自动化的检测。

可能到最后只能靠人去检查，但鲜有能分到这种事情上的人力资源。

重写 window.fetch 可太秀了，没见过的操作算是学习到了 😂

这是个历史遗留，目前来看用处不大了。效果基本等价于你写代码片段。

配置文件建议直接通过 saveData 存成 json 文件。

大的资源文件建议放到 /data/public （或者别的目录下），然后通过调用 putFile 等 API 来进行 IO 操作。

点进去添加一个 css 片段

需要频繁编辑比较长的嵌入块，推荐使用「文档流」插件，将嵌入块内容在文档流中打开后编辑起来会方便很多。

编辑器的对比度可以，方便阅读，这个好。

但是建议对不同层级的标题做一下区分。

我个人更加倾向颜色使用必要但克制，阅读体验清晰的风格。

你说的情况就相对复杂一些了。

我说的 「onunload 里面不要 saveData」 是表象。核心的关键其实是两点：

1. 思源会先启动插件再做同步
2. 同步数据完成后，思源有可能会 reload；reload 的过程中会调用 onunload 钩子

面对复杂一下的情况，就需要把握这两点进行具体分析了。

思源的群主要就是 1 2 3 群和折腾群了。

可以用这个 quicker 动作：

粘贴 GPT 数学公式 - by Frostime - 动作信息 - Quicker

我投一票赞成。

这属于 SQL 的问题。

限制只查询文档的话，就加上 type='d' 条件。

限制笔记本就用 box='笔记本ID' 做限制条件；子文档就用 path like '%文档ID/%' 做限制条件。

vite-svelte 模板提供了热重载，但是这个热重载本质是检测到文件发生变动就自动 window-reload。和无需刷新的热重载可能还有点差距，但其实日常使用也能用。

你如果不想要使用 node 环境开发，可以试一下‘开发 API’或者‘Run JS’。

这两个插件都把一些前端的 API 透传到了 globalThis 下面（RunJS 还透传了一些对 kernel api 的封装），这样直接在思源里面就可以调用一些给插件用的 api 了。

同意，比起评分，点赞会更好一些。前者会带来负面效应，后者则一般不会。

甚至可以放宽一点，允许用户重复点赞，从而和下载量做区分。

你们“为爱发电”开发软件的时间值钱，难道成千上万大众的筛选软件的时间成本就不值钱吗？

你这就是属于强行制造对立，混淆概念了。

「筛选软件的时间成本」和开发者开发软件没有直接关系，那是各种教程、分享、交流应该负责解决的事情。

只是说在这个案例里面，某人提出的针对「筛选软件的时间成本」的方案可能带来对开发者积极性的负面影响，这属于技术性问题，是方案设计的不够好的问题。比如某些插件被刷了低分、差评，那于作者而言是不是干脆下架插件，眼不见心不烦为好？——考虑到思源的社区规模比较小，目前不适合应用这种模式。（不过或许可以换成点赞这种只有正向反馈的模式，这个可能会好一点）。

总结一下就是：

• 「“为爱发电”开发软件的时间」和「成千上万大众的筛选软件的时间」这两者之间不存在内生性的矛盾，这个矛盾是被你人为拼接出来的。
• 你提出的核心矛盾是有问题的，所以你后面的就题发挥均没什么讨论的价值；任何字斟句酌都变成了无聊的对概念的辨析和对定义权的争夺。
• 如果你真的想要进行有意义的讨论，那也应该是技术性的，比如：如何在不影响开源作者的积极性的前提下构建一个有参考的评价、分享系统。

至于你强行把开源作者和普通用户对立，我只能这么说：

不一定需要复制出来，插件「集成编辑环境」是可以以 markdown 的格式修改笔记的内容的。

可以写个脚本定时调用内核的导出 API

https://github.com/siyuan-note/siyuan/blob/f7920fa853a2e5ad1ecb114d0bc54c039d5e5be5/kernel/api/export.go#L253