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
Related
As described here, emacs-lisp-mode provides for special handling of s-expressions in docstrings that start in the first column. This requires them to be escaped with a backslash to avoid mucking up font-lock later on in the file.
This may be a feature for elisp, but is unfortunate in other lisp modes that reuse emacs-lisp-mode for convenience that don't have special handling of expressions in docstrings, as described/shown here.
My question is, is there any way for such "descendant" modes to configure emacs-lisp-mode to disregard "calling convention expressions" in docstrings?
The short answer is no.
The longer answer is that those other modes are simply broken. They should adapt to Emacs Lisp in this regard. There is no reason not to, is there? It is simply a bad idea to use workarounds (e.g. indent all doc-string lines), such are suggested in the link you provided (and its linked duplicate post).
Emacs doc string are not trivial strings. They have several special properties, including the handling of \\[...], \\{...}, and \\<...>, as well as the property you mention here.
If some mode cannot adjust to Emacs doc strings then it should use macros that define the things it needs without creating Emacs doc strings for them but by handling a different string argument in the special way desired. IOW, create pseudo doc strings that correspond to what the mode wants instead of what Emacs wants.
Of course, that means that you cannot directly take advantage of the Emacs documentation features. You would need to also define mode-specific doc commands that would, for example, wrap the existing doc functions such as describe-function with code that picks up the mode's pseudo-doc string and DTRT, following the mode's conventions instead of the Emacs doc-string conventions.
But I would think that the easiest approach would be to just adapt the mode to the existing Emacs behavior, so that it DTRT.
Many Emacs programming modes, and various Lisp modes are no exception, have been implemented based on parsers with regular expressions. This, unfortunately, gives the editor little idea of the document being edited. Eclipse, for example, has a very different idea of how to edit code, which is more structured, and JetBrain MPS editors are even more rigid and structured in this sense (almost like spreadsheets).
This makes Emacs modes faster and easier to implement, but it also means the code that supports the proper indentation, syntactic validation and highlighting has to re-parse more text every time it is being edited. CEDET, afaik, is trying to address this issue.
Thus, historically, there had been conventions designed to reduce the amount of code to parse on each edit. Parenthesis in the first column is one such convention. However, it also has been known to be an annoyance some times, that's why there's a open-paren-in-column-0-is-defun-start variable one can set to nil to inhibit this behaviour.
But It's hard to say what exactly the performance issues you may face when changing this setting. Lisp grammar is very regular, unless you are using many reader macros, so, perhaps, that won't be a problem.
If beginning-of-defun-function is set accordingly, i.e. checking if inside a comment or string, should be no need for such escaping.
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 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 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
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).