How to efficiently search Info documentation? - emacs

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.

Related

Banish unmatched top-level trees when performing tag search in Emacs 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).
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.

In Emacs how to operate (i.e. search) only in code regions?

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

Doing a different kind of completion

I am writing a function that uses the minibuffer and requires a somewhat different style of completion that might require deleting some characters. For example:
ar<tab> -> artist:
artist:ba<tab> -> artist:'Johann Sebastian Bach'
artist:'Johann Sebastian Bach'<tab> -> artist:'Bela Bartók'
artist:'Bela Bartók' and album:<tab>
etc...
I've already written the completion function, that generates a list of possible strings for the current input, yet I cannot use it with completing-read and completion-table-dynamic, because only the alternatives that do not require deletion are displayed. In this case, only the first step, from ar to artist.
To do the job, I'm considering using the lower-level (read-from-minibuffer) with a custom keymap to do the completion and display the alternatives. Is there a simpler solution? If not, which functions are there to handle displayed and cycling through the Completions buffer?
Thanks!
EDIT: In the end, I rolled my own. Here is the code, if anybody's interested.
Yes, Icicles should give you what you want, IIUC.
I'm not sure how you're handling things like 'artist' and 'album', but there are a few ways Icicles could help.
You can match parts of a completion candidate in any order. So if 'foo' and 'bar' are parts of the same candidate, then you can match any candidates that have both, in either order. This is "progressive completion": you can keep adding patterns to narrow the choices. Patterns are ANDed. You can also subtract candidates that match a pattern.
You can have candidates that are "multi-completions". These are composed of parts, separated by a configurable string. You can match against any or all parts. So, for example, a candidate might be an album name plus artist names.
If you also use Bookmark+ then you can tag files, a la delicious.com tagging. You need not visit files to tag them. Tags are generally strings (including newlines if you want), but they can also have associated Lisp values. Here, you might have a file for each album and tag albums with descriptions and various artists. Then you can complete to find a given album file by matching parts of its name and/or artists.
For all Icicles completion, you can use progressive completion and complementing (#1). For each part of a progression you can use substring or regexp matching (or even fuzzy matching of various sorts).
Some links that might help:
http://www.emacswiki.org/emacs/Icicles_-_Progressive_Completion
http://www.emacswiki.org/emacs/Icicles_-_Multi-Completions
http://www.emacswiki.org/emacs/Icicles_-_Bookmark_Enhancements -- see, for example, command `icicle-find-file-tagged'
You may benefit from the Icicles library. It contains many features for enhancing minibuffer completion.

What's the best Find in File mode for EMACS?

What's the best package for finding a string in multiple files in EMACS. I know about grep and such but I would like something that is a little smoother to operate.
There are three builtin functions for grepping in Emacs: grep, find-grep (or grep-find) and rgrep.
The first two work by letting the user edit the grep command line directly.
I usually use the third, rgrep, from "recursive grep". It's a little friendlier, as it prompts the user for the search parameters (search string, file types and directory) one by one, provides customizable defaults, and it automatically ignores some common files and directories you usually don't want to search, like for example .svn or .o files.
Then, there is ack, and its interface for Emacs: ack.el, whose default behavior is similar to rgrep, but can be customized to use the options that ack provides.
Just in case you haven't read it already - there's lots of relevant tips over at the EmacsWiki GrepMode page.
Dired mode also lets you do a search through marked files with the dired-do-search function.
And ibuffer lets you do emacs' generic isearch through a bunch of buffers using the awkward key sequence M-s a C-s.
As an alternative, I find dired-modehelpful, especially when used with either dired-mark-files-regexp (%m) or dired-mark-files-containing-regexp to select what should be searched and then dired-do-search (A).
Depends what you mean by find a string. As others have mentioned, grep is very good at what it does. I use it all the time, everyday.
But if your "string" is, say, a sequence of words within a sentence (which can be multi-line), then grep might not be what you want.
Another tool for searching across multiple files or buffers (or bookmarks) is Icicles search. The general idea is that it first parses the files into search contexts according to some definition (e.g. a regexp), and then it searches for matches to your current minibuffer input (changing the search hits dynamically as you edit your input).
Whereas grep always uses lines as search contexts, with Icicles search you are not limited in how you define the contexts to search. The contexts need not partition (exhaust) the file; they can cover as much or as little of the file text as you want.
Among other possibilities, you can use Emacs thing-at-point definitions for various kinds of THING as the search contexts. For example, you can use command icicles-search-thing with sentence as the THING type, to use sentences as the search contexts.
Or you can use character-property zones as search contexts: search all zones that are font-locked with a given set of faces, for instance. There are many possibilities.
http://www.emacswiki.org/emacs/Icicles_-_Search_Commands%2c_Overview

What is the best way to navigate duplicate tag definitions in Emacs?

Within emacs, what are the best options out there for navigating to a specific function whose name might show up across several different files? Within etags, you are only allowed to cycle through the tags one-at-a-time which could take a while if the function name you are looking for is popular.
C-u M-. cycles all locations of the same tag, but if you want to see a list of all tags that match your function name you can use the command tags-apropos.
Etags-select:
http://www.emacswiki.org/cgi-bin/wiki/EtagsSelect
If your programming language is C then cscope is much better than etags. It presents you with an interactive list of a symbol instances with its context. More info is in this answer
Icicles tag commands
In particular, use command icicle-find-tag, to do what all of these vanilla commands do:
find-tag (M-.) to find a tag
tags-loop-continue (M-,) to find another matching tag
tags-apropos to list all tags that match a regexp
list-tags to show all tags (definitions) in a given source file.
icicle-find-tag is a general tags browser: being a multicommand, you can visit any number of tags, in any order, in a single invocation.
Icicles imenu -- Imenu across files or buffers. Search within selected function definitions (as the search contexts).