在Emacs Org模式下执行标签搜索时，消除无与伦比的顶级树 [英] Banish unmatched top-level trees when performing tag search in Emacs Org Mode
问题描述
在过去的一年半中，我在Org模式下与我的当前雇主一起为我的工程笔记维护了一个整体缓冲区.尽管大多数文件都包含指向其他文档的指针，但按照人类标准，该文件已经变得很大(48,290行文本)，并且仍然可以通过编程方式(请参阅:grep和Org Mode标签搜索)轻松地进行搜索和编辑.
For the past year and a half, I've maintained a monolithic buffer in Org Mode for my engineering notes with my current employer. Despite containing mostly pointers to other documents, this file has become quite large by human standards (48,290 lines of text), while remaining trivially searchable and editable through programmatic means (read: grep and Org Mode tag search).
不过，有一件事困扰着我.当我使用Org Mode 6.33x 执行标记搜索时，Org的稀疏树视图将保留折叠的缓冲区中不匹配的树的表示形式(即，内容前带有单个星号*).通常，这对于较小的缓冲区或更好地组织成具有多个分支的单个树的缓冲区很有用.但是，这对于按时间顺序生成每棵新树(每天都生成一棵新树)的文档来说效果不佳.
One thing bothers me, though. When I perform a tag search using Org Mode 6.33x, Org's sparse tree view retains the folded representation of unmatched trees within the buffer (that is, content preceded by a single asterisk, *). This is generally useful for smaller buffers or those better organized into a single tree with multiple branches. However, this doesn't work especially well for documentation where each new tree is generated chronologically, one for each day, as I've been doing.
.
在继续之前，我会注意到我的变通办法是我刚才问的固有问题，与此缓冲区有关，我的文档习惯也发生了明显变化.但是，仍然存在以下问题:
Before I continue, I'll note that my workaround is inherent in what I've just asked, as are the obvious alterations in my documentation habits with this buffer. However, the following questions remain:
1)为什么执行稀疏标签搜索时，组织模式会以这种方式组织树?技术细节是不言而喻的，UX的决定则更少.
1) Why does Org Mode organize trees in this manner when performing sparse tag searching? The technical details are self-evident, the UX decisions less so.
2)如果我想使用Emacs Lisp编写的脚本来纠正此问题，我应该更详细地探索哪些挂钩和命令来重构文档视图?为标准命令(例如 org-match-sparse-tree )编写替代代码已经不言而喻了.
2) If I wished to correct this issue with a script written in Emacs Lisp, what hooks and commands should I explore in more detail to restructure the document view? Writing overrides for the standard commands (for example, org-match-sparse-tree) is already self-evident.
.
谢谢.
推荐答案
您已经注意到，该问题仅影响顶级标题.好消息是，在组织模式下，您可以通过简单的击键轻松将所有标题降级.这样您可以避免该问题.清除之后，还需要进行一些简单的按键操作.
As you already noticed the problem only affects the top level headings. The good thing is that in org-mode you can demote easily all headings with simple keystrokes. This way you can avoid the problem. Also cleaning up afterwards are just some simple keystrokes.
分步说明:
- 标记整个缓冲区
- 呼叫 M-right (用于
outline-demote) - 在文件开头输入
* root \ n - 现在，建立您的子树并使用它来做您想做的事.
- 完成后，您可以删除文件开头的
* root \ n并使用 M-left 再次升级标题.
- Mark the full buffer
- Call M-right (for
outline-demote) - Input
* root\nat the beginning of the file - Now, build up your subtree and do what you want with it.
- When done you can remove
* root\nat the beginning of the file and promote the headings again with M-left
我给您的印象是，您甚至可以将总体标题保留在适合您的应用程序的位置.
I have got the impression that you can even leave the overall-heading where it is for your application.
这篇关于在Emacs Org模式下执行标签搜索时，消除无与伦比的顶级树的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
