logseq 这类软件我始终认为只适合用来打草稿，大纲结构的信息在遗忘结构后，再次查看就是灾难。一个例子就是我们产品用大纲来作为需求文档，层级多，信息查找困难，零碎。双向链接并不能拯救这种混乱。
不敢苟同。大纲是已经处理好的信息结构，而段落式文本是未处理的。当你重新读一段文字的时候，实际上是要重新parse这段文本，提取其中的语义，而读大纲就完全不需要。
其次，大纲的结构容许无限层级缩进，可以以任意喜欢的粒度补充信息，在不需要的时候可以折叠起来，想看就看，非常清爽。
不过，我认可做得不好的大纲读起来是灾难，但是写得不好的段落式文本难道就不是灾难了吗？ 
2 个赞
我主要是讲体验，但「使用体验」在截图上是看不到的，而且隐私太多，恕不能提供。抱歉啦。
无限层级请参考 node_module，简直就是灾难。
但是org-mode本身就是大纲式的
从来不用org-mode，直到org-roam出现，好用到哭。
从此把mweb（macOS下的markdown笔记管理软件）废弃了。
我说的是写笔记啊，不是日程管理，GTD啥的。
2 个赞
握手。
我现在基本不写代码了。 但还是在用emacs， 就是因为org-roam。
体验很不一样的。org-mode 的“大纲”式可能还是更接近于普通的 headline，但可以折叠。从这个意义上说，MS Word 也可以说是大纲式的了。
如果你在logseq里将文件格式设置为org，那么打开它存储的文本文件，就能发现它正是用headline作为大纲的。
我知道，但是 Org 的使用体验——即使是像这样用——也和一般的大纲软件很不一样。
我觉得 org-mode 设计就是为了写长文本的。我举个例子你就知道了，我之前学习拉丁文，我先是在 Emacs 里面做笔记，然后源文件长这样子：
** Nominative
There is two situation that must nominative should be used.
1. Nominative subject.
2. Predicate Nominative.
*** Could you please give an example for subject nominative? (In english)
#+begin_quote
He is a waiter.
#+end_quote
"He" in the upper sentence is Nominative Subject.
*** Could you please give me an example for Predicate Nominative? (In english)
#+begin_quote
He is a waiter
#+end_quote
"a waiter" in the upper sentence is Predicate Nominative
但如果使用 logseq 打开就会非常难看，因为它看上去虽然是一条条的笔记，但实际上还是用“Heading-Context”式组织内容的，我也因此而拒绝使用 logseq 非常久。
然后后面我使用了 logseq 来重新整理，就变成了下面这样：
我做了如下的调整：将那些举例子之类的 Context 全部藏到新的 page 里面，并且放弃使用 1 2 3 这种 list 来枚举这个格的所有可能用法，而是直接使用 heading 来枚举。
这调整是非常小的，但是产生了一种根本思路上面的转变：即从 heading+context 为中心的内容组织方法彻底倒向 heading 为主的组织方式，基本不写内容，或者将内容藏在链接里面。这点其实 org-roam 是可以做到的，但就像上面老哥说的，总感觉在 Emacs 里面这么做不是非常得劲。
这样好处是巨大的，首先就是它减少了我的心智负担，因为我之前写笔记的时候总觉得光一个 heading 非常难看，总要没事找事填充点内容，然后写了长文本却从来不回头去看。但是切换到这种大纲式的笔记方式之后，我就少了非常多的压力。当然这点只是我的问题。其次，它使得整个笔记变得整洁，而提升了可读性。我觉得写长内容写的时候可能非常爽，但是回头看就非常难受，简直是一种折磨。而若是将内容藏到链接里面，我感兴趣的内容就去点开研究一下，不感兴趣就略过。再最后，org-mode的功能太过于丰富了，比如任务计时功能，我经常会计时自己的TODO项目，但后面发现我如果后面从来不去总结回顾，计时又有什么意义呢？我用 org-roam 的时候就会忍不住去折腾这些，所以现在离开它就能多很多时间放在事情而非工具上面。
6 个赞
计时这个确实有体会，之前想利用 org 记录自己的时间使用情况，但是最后也只是简单的记录，没有最终形成一个闭环。
现在想想，其实可能我是希望有一个总结的界面，例如按月、按周进行总结回顾时间使用的情况，这个就只能靠hacking了。
赞同，我也有类似体验。对于TODO管理、读书笔记、月度总结等日常场景来讲，logseq的模式更加简洁自然，写起来心理负担也小，有利于让自己回归到写作和思考本身上来。
而针对技术文档readme场景来讲，感觉还是org-mode模式更好。org-mode就是个工具箱，根据场景来选择合适的工具很重要，而不是一股脑全用上。Sometimes less is more.
1 个赞
我觉得你举的例子表明你在 org-roam 和 logseq 中的实践还是有点不一样的。
你在 Logseq 中的实践遵循了笔记原子化的准则，而在 org 中你没有这样实践。导致你的笔记在 Org 中显得很长，很乱。
org 不一定是要写长文，短的也可以，需要每一则笔记尽量遵循笔记原子化。你第二张图给的是 logseq 中的大纲，这很像 zettelkasten 中的 outline 或者 register。这些也可以在 org 中实现。
3 个赞
Hyperbole 似乎也是这种 heading 更像 bullet list 的设计。
现在有clangd+citre，写个cpp倒是很舒服，可能需要改一改喂给lspserver的参数。
邮件日程管理确实不好使，不管怎么说org和emacs不太适合处理这种，怎么描述，很适合一边吃饭一边随便点点的事情。
要不试试 logseq?
1 个赞
刚刚试了以下，真是个好东西。
最近因为手机损坏，换上了苹果手机，我也放弃了使用 org-mode 管理日程，笔记管理还是得用 org-mode。
苹果电脑配苹果手机，系统自带的日历和提醒事项就己经足够使用。这个组合比电脑用 emacs，手机上用 beorg 好一些。但是我不知道 beorg 用上插件是不是会好一些。
使用 org-mode 管理日程，可以进行时间统计，但是柳比歇夫的奇特一生很难。
大佬的文章面向的对象是研发人员，但是我觉得对其他人也有借鉴意义。重要的是做事情的时候足够专注，可能就不需要记录时间都去哪了。
https://manateelazycat.github.io/think/2023/05/10/developer-focus.html
1 个赞
关于这篇文章第一点，我感觉Linux上开Steam打游戏还是很爽的，前天玩东方不小心打到一点多。。。
1 个赞