I'm trying to explore my org file using sparse trees.
I'm having trouble combining positive and negative conditions with tags with special characters. Here's some searches I've tried (with C-u C-c / m):
{-"#vigo"&{SCHEDULED={.}|DEADLINE={.}|TODO="NEXT"|TODO="WAITING"|focus|PRIORITY={.}}}/!
-#vigo&{SCHEDULED={.}|DEADLINE={.}|TODO="NEXT"|TODO="WAITING"|focus|PRIORITY={.}}/!
What I'm trying to express is: any headlines without the tag #vigo, which are scheduled, have a deadline, have todo keywords NEXT or WAITING, have the tag focus OR have a priority.
When I use any of the search queries above, entries with the tag #vigo are highlighted. Why?
The manual states that "Parentheses are not implemented": http://orgmode.org/org.html#Matching-tags-and-properties, so you have to distribute the -#vigo across all the ORs:
-#vigo&SCHEDULED={.}|-#vigo&DEADLINE={.}|...
Untested.
Related
I was looking for documentation on tr program. As you would imagine the combination of characters t and r happens fairly often in English language... Although I was sure about the name, I wasn't sure about the name of the section it belongs to, so I had to display all nodes and try searching for something like tr or tr( and so on.
Isn't there a better way to do it?
Hmm... I can only guess that the following isn't happening for you; however nodes for individual programs really ought to be listed in the top-level directory, and hence show up when you type M-x info RETd, from where you can simply use m tr RET.
However if you're searching for something which isn't in any of the directory files, the only convenient thing I know of is M-x info-apropos (which searches all of the indexes rather than the node titles).
And of course within a given manual you can use I to search its index, which is much faster than searching all of them.
Edit: This is tangential, but an excellent improvement in the upcoming Emacs 24.4 (currently undocumented in the NEWS file) is completion for Info node names in non-current manuals.
e.g. C-hig (elisp) TAB now provides completions for all the nodes in the elisp manual, even if you are not currently viewing that manual.
This is an extremely welcome change!
Icicles can help here. All Info commands that use completion let you take advantage of Icicles completion features. This includes apropos completion -- regexp matching, which means that you essentially get on-the-fly info-apropos behavior, among other things. And it includes progressive completion, which means you can add additional patterns to progressively narrow your search.
When completing you can sort the candidates in various ways, including sorting Info nodes in book order for g.
g (icicle-Info-goto-node) lets you search both node names and node contents at the same time: Your minibuffer input can contain a second search pattern that is matched against the node contents. The completion candidates are those whose names match the node-name pattern you type (if any) and the node-content pattern you type (if any). Each pattern is a regexp (which includes substring matching as a simple case).
See Icicles Info Enhancements for more information.
I want to use the capture module of org-mode to create a data base of new words that I want to learn, and then use the drill module to learn them (flash cards style).
In my org-capture-templates I added the following:
("v" "Vocabulary" entry
(file+headline (concat org-directory "/vocab.org")
"Vocabulary")
"* Word :drill:\n%^ \n** Answer \n%^")
This is a rather naive template which I borrowed from here. It works fine but it is too limited. Unfortunately I'm rather new to elisp and I don't know how to improve it.
I think the above template has to be improved in the following there aspects:
Headline Currently the first input string is the (new) word and the headline is fixed. How can the headline be the same (input) word? I think that the following result is desirable:
* Vocabulary
** Foo :drill:
Foo
*** Answer
What is foo
Actually an even better way would be to have 3 input strings.
The new word (for example foo) which will be the headline.
If the second is empty, then it gets the same string as (1). Otherwise, concatenates the string to the one from (1). E.g. having as second input bar would yield foo bar. This will be the content of the entry.
The word's definition which should come in the answer sub-headline.
Duplications (see again this) If at some later point I try to capture foo again, I would like to know it, and be directed to edit the already existing entry - skipping all the inputs.
Sorting After capturing I think it would be nice to sort the list of words. This should not be too hard given that the headline of each entry is the word itself. In this case one can probably use the org-sort-entries function.
I know this is a rather big questions but I also think that if it can be solved here it will be of great use to many users.
Edits:
Using #juan_g suggestions, I improved my template and now it is:
("v" "Vocabulary" entry
(file+headline (concat org-directory "/vocab.org")
"Vocabulary")
"* %^{The word} :drill:\n %t\n %^{Extended word (may be empty)} \n** Answer \n%^{The definition}")
I didn't manage to set the default value of the second input to be the 1st one. I tried something like %^{Extended word (may be empty)|%\1} but it returns ^A which is not helpful.
In any case, this improved version seems to be already usable.
About the input question, in Org Mode Manual: 9.1.3.2 Template expansion, there is the %\1 special escape code:
%\n Insert the text entered at the nth %^{prompt}, where n a number, starting from 1.
The duplications question probably would need some Emacs Lisp coding.
For sorting, see C-c ^ (org-sort).
BTW, org-drill seems indeed a really interesting package, based on SuperMemo's spaced repetition algorithms.
You need an extra "\", therefore %\\1 works as expected.
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).
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) 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) 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.
.
Thank you in advance.
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.
Step-by-step instructions:
Mark the full buffer
Call M-right (for outline-demote)
Input * root\n at the beginning of the file
Now, build up your subtree and do what you want with it.
When done you can remove * root\n at 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.
I'd like to isearch/search-replace/occur only in code (that is not in comments or strings).
This must be a common problem, so what packages do this already?
If no existing packages do this, I'm thinking a minor-mode where strings and comments are hidden based on fontification would do the trick. Is there one?
Icicles search gives you several ways to do this. Here are two:
Search "things" (e.g. defuns, sexps, xml elements, etc.), ignoring comments (option icicle-ignore-comments-flag). That is, use selected code segments as search contexts, but ignore any comments within code or code inside comments.
Search the complement of the comments. E.g., define the search contexts as the complement of the zones of text that are font-locked with either face font-lock-comment-face or face font-lock-comment-delimiter-face (which means search all code outside of comments).
After defining the search contexts, just type text to incrementally filter the contexts. And you can replace any matches on demand.
Check out narrowing.
Yes, you are right. The HideShow minor mode allows you to hide/show block of text, in particular multiline comments.
The hide/show comments is not part of the standard package but on the wiki page you will find the code which does the trick.
Then isearch command does not take into account the hidden comments.
HOWEVER: replace operates on the whole buffer, including hidden blocks.
Isearch+ does what you ask (as does Icicles --- see other answer, above).
You can define the contexts that Isearch searches, using any of the following:
A regexp to be matched.
A given text or overlay property --- The search contexts are the text zones that have the property (e.g. a particular `face' value or combination of values)
A given Emacs THING (sexp, defun, list, string, comment, etc.) --- The search contexts are the text zones of the given THING type.
Having defined the search contexts, you can also search the complement: the non-contexts. You can toggle between searching contexts and non-contexts anytime in Isearch, using C-M-~.
When searching, by default the zones not being searched are dimmed slightly, to make the searchable areas stand out.
For context-searching with Isearch you need these two libraries:
isearch+.el
isearch-prop.el
I'm missing one piece in Emacs' already superbly unique completion system (completion-styles and completion-styles-alist), namely word and sub-word-reordering a la google search.
As an example, file-write should complete to write-file if no other style finds a completion. Word-separating characters could for-example be matched using the regular expression "\\s_".
Even cooler and more general would be if applied the Damerau-Levenshtein Edit Distance (D) to words instead of letters. The completion candidates could the be sorted on increasing distance D, meaning closest match first.
My plan is quite clear on how to implement this and an implementation of D already exists. I ask anyway so I don't reinvent the wheel yet another time:
Has anybody implemented such a completion style already?
Per --
You cannot do what you want with vanilla Emacs (well, you can use Lisp to code whatever you need -- but you cannot do what you want not out of the box).
Icicles gives you exactly what you want. It's called "progressive completion", and the idea is similar to using a pipeline of grep commands.
Nutshell view of progressive completion (and chipping away the non-elephant)
Progressive completion
You can also use LevenShtein matching for completion with Icicles, and combine that with progressive completion to match the words in any order.