我在用，感觉目前比较适合工作流不那么复杂的用户。
- denote有一套文件命名的规则，基于这个规则根consult-note结合可以做简单的搜索。
- denote提供了一个denote的link格式，支持md，org，txt，只能定位到文件不支持定位到heading，有backlink（基于xref，把xref后端换成ripgrep速度还不错）。
这个包按prot自己的说法不是zk类笔记方法的平替，甚至不会依赖太多org的特性，建议觉得org-roam太重很多功能用不上的用户使用。
现在的这些笔记插件都是 zk 那一套，不知道那种层级结构，我还是喜欢像 dendron 那样的，dendroam 虽然仿照了 dendron，但没有 publish 和一个好的 tree view 界面。
可以使用 consult-notes 这个包，我下午试了下，非常不错：
(use-package consult-notes
:straight (:type git :host github :repo "mclear-tools/consult-notes")
:commands (consult-notes
consult-notes-search-in-all-notes
consult-notes-org-roam-find-node
consult-notes-org-roam-find-node-relation)
:bind ("C-c d f" . consult-notes)
:config
(setq consult-notes-sources
'(("denote" ?d "~/Documents/notes")
))
(consult-notes-org-roam-mode) ; Set org-roam integration
)
2 个赞
非常喜欢这个插件的文件命名方案！
即 日期+题名+标签的方式，好处是在不打开文件的前提下能够确定文件的主要信息（如文件创建的时间，文件内容摘要，及文件的分类）。
个人推荐！
1 个赞
这不错，一直还没怎么想清楚展示的问题。你的配置可以分享一下吗？
其实楼上 patrolli 提到的 dendroam 的命名方式会更高效，你可以了解一下看看。我简单解释一下，它是属于 3 段式命名，例子：
[领域].[话题].[具体概念]
工具.效率.org-roam
你也可以根据你自己的需求往下拆分。
其实这种命名方式挺好的，因为从原则上是贴近原始的 zettelkasten 命名法——只不过卢曼把它抽象成了数字+英文字母的组合。但现代工具，可以不受记录空间的限制的话，可以更加自由。
2 个赞
最近已经从org-roam彻底转成denote了，主要是实在忍不了大文件（包含很多link的org文件，我一般很多线上培训都会截图，都是link）每次保存的时候，org-roam默认都会有个hook去做链接替换，每次保存都要5s以上。而且，用了许久org-roam，好像高阶功能都没怎么用到。
现在用denote+consult-notes+org-super-links用起来很爽，是我想要的工作流。
4 个赞
希望哪天可以详细介绍下
看了看文档，文档很详细。只要接受文件命名方案，应该是一个不错的解决方案，试用看看。
又有人从 denote 跳回 org-roam 了。
这个包真的不错，我从中学会了用 consult-read 的方式，在org-capture时有预览地选择 org 文件。
比如要capture到notes文件夹下的某个org文件里，用consult-notes的方式去选择。
代码见 https://github.com/ingtshan/.misc.d/blob/main/doom/custom-consult-notes.el#L38
在学+用中。目前就大致看了一下文档，基本上就最小配置，用denote的命名方案+consult搜索，配合citar-denote做文献阅读。
原本用org-roam，可能是我的Windows本设置不对，每次db-sync都会卡，甚至卡死桌面，没用几天，只好换这个不依赖数据的了。
不过很喜欢denote的笔记命名方案：时间戳+题目+tags，这样单凭everything进行文件名检索也能很快了解到笔记内容。双链denote本身支持page级别，也没有像类ob roam双链笔记倾向于小文件，可自行组织决定笔记结构篇幅。个人用ob logseq时就一直不习惯太多小文件，使用denote感觉就灵活很多。
目前问题以及以后想看看怎么改进的主要还是backlink。（双链笔记中，个人觉得相比于图谱ui，backlink更为重要。）
但denote的backlink……一是基于ripgrep检索backlink还是很慢很慢，不知道是不是Windows平台的原因，但按关键字检索笔记全文速度又蛮正常的。二是基于doom配置，denote backlink buffer区乱码，看git issue也还没解决。 
果然Emacs就是要折腾啊
可以试试ugrep，比ripgrep快一点
谢谢，试了一下速度果然快些。 
但backlink还是乱码不支持中文名，只好暂时不用这个功能。
估计是编码问题，windows默认不支持utf-8，emacs里面需要转换一下，贴下我的配置你参考下试试。gbk-dos是中文简体windows的默认编码
(setq-default process-coding-system-alist
'(("[pP][lL][iI][nN][kK]" utf-8-dos . gbk-dos)
("[cC][mM][dD][pP][rR][oO][xX][yY]" utf-8-dos . gbk-dos)
("rg" utf-8 . gbk-dos)
("ug" utf-8 . gbk-dos)
("ugrep" utf-8 . gbk-dos)
("es" gbk-dos . gbk-dos)
("explorer" gbk-dos . gbk-dos)
("*" utf-8-unix . utf-8-unix)))
1 个赞
我用的doom emacs，win11开启了utf-8支持，原本的配置是：
(setq locale-coding-system 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(set-selection-coding-system 'utf-8)
(set-default-coding-systems 'utf-8)
(set-language-environment 'utf-8)
(set-clipboard-coding-system 'utf-8)
(set-selection-coding-system 'utf-16le-dos) ;; 解决粘贴中文出现乱码的问题
(set-file-name-coding-system 'utf-8)
(set-buffer-file-coding-system 'utf-8)
(prefer-coding-system 'utf-8)
(modify-coding-system-alist 'process “*” 'utf-8)
(when (display-graphic-p)
(setq x-select-request-type '(UTF8_STRING COMPOUND_TEXT TEXT STRING)))
无论文件名是英文还是中文，backlink buffer区都是乱码。参考你的配置之后英文文件名中的反链可以正常显示了，中文文件名则完全检索不到了 
我贴的配置和这一行(modify-coding-system-alist 'process “*” 'utf-8)修改的是同一个东西，如果你已经启用了windows的unicode支持，按理说doom的这个设置没问题，，，也许可以试试这个基于 ripgrep 的代码搜索和重构工具 - #62，来自 Angelaneia
我试了依旧不起效。不过确定是编码问题那我就再找找。thx！ 