I like rgrep a lot. The interface for finding and jumping between matches is great.
But I also want the ability to do interactive and non-interactive replacements
from the *grep* results window.
I mean the information for replacing is already laid out perfectly:
the thing to be replaced is nicely highlighted
some context is given (although it wouldn't hurt to bind
+ to increase the number of context lines)
the files and positions are here as well
But there's no interface for replacement (I checked with f1 m).
Did I miss it or it's not available? Or is it available is some package?
I think you are looking for wgrep. It uses wdired approach, and it is available in the usual package repositories.
Related
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.
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
There are several questions on SO about how to get code folding in emacs, without having to add any special characters like "markers" in the comments for example. Someone said that there was "no perfect solution."
It seems that it could be done by parsing the source of the program being written and look for matching parenthesis or bracket, or to do it based on indentation. You could also use a combination of scripts that use different methods.
So why is it commonly accepted that there is no "perfect" and straightforward way to get code-folding in emac? Is there something in emacs or its architecture that makes it hard to program? If it were easy, after so many years of smart people using emacs you would think that someone would have wrote it.
You should play with Hideshow (hs-minor-mode) combined with fold-dwim.el. It does exactly what you suggested -- looks for matching braces/parens, and can be set up to fall back on the indentation.
There's a robust folding solution out there for most common languages, and if there isn't, all the folding packages are highly customizable. In fact, the only downside is the proliferation of folding methods (fold-dwim helps quite a bit with that); I used to think that because nobody could point me to a definitive solution, folding was hard or impossible — in fact, the opposite is true. You just have to experiment a little to see what works best for you.
I have used folding.el (e.g. to group stuff in my .emacs), outline-minor-mode, and now Hideshow. There's some chance that none of them would work exactly the way you want right out of the box (e.g. you might need to set up an outline regex, or define folding marks for folding.el), but it turns out to be easy. The default keybindings can be somewhat baroque, but this is remedied by fold-dwim and/or hideshow-org (highly recommended for Hideshow, cf the Emacswiki hideshow page; you can also mimic hideshow-org's behavior for other folding modes with some quick-and-dirty elisp and fold-dwim). Once you figure out your preferred setup, just turn it on automatically via hooks or buffer-local variables, and watch your code fold away :)
You should look into CEDET. It does code-folding just fine, and many other fancy features that you're probably looking for if you're switching from an IDE to Emacs.
http://cedet.sourceforge.net/
Specifically, look for `global-semantic-tag-folding-mode'
You don't need anything extra, just enable outline-minor-mode for file types you want to fold.
But in fact, there ARE various solutions for Emacs; I have listed some of them (those I have happened to come across) at http://en.wikipedia.org/w/index.php?title=Code_folding&oldid=375300945#cite_note-2.
Though, there are things I'm missing: in some cases, I'd like to combine several mechanisms: for example, for markdown, I'd like to use outline-based folding (for sections) and indentation-based folding (for quotations, code blocks etc.) -- in order not bother with implementing a complete parser for markdown.
Here they are:
Token-based folding in Emacs
Token-based folding in Emacs is impemented by the folding minor mode.
Indentation-based folding in Emacs
One can use the set-selective-display function in Emacs to hide lines based on the indentation level, as suggested in the Universal code folding note.
Syntax-dependent folding in Emacs
Syntax-dependent folding in Emacs is supported by:
the outline and allout modes
for special dedicated "outline"-syntaxes;
by the hideshow minor mode for some programming languages;
also,
by the semantic-tag-folding minor mode and the
senator-fold-tag command for
syntaxes supported by semantic,
as well as by doc-mode for JavaDoc or Doxygen comments,
by
TeX-fold-mode
sgml-fold-element command,
nxml-outln library
in the corresponding language-specific modes, and possibly in other modes for particular syntaxes.
Several folding mechanisms are unified by the
fold-dwim interface.
See also http://www.emacswiki.org/emacs/CategoryHideStuff.
Folding of user-selected regions in Emacs
Folding of user-selected regions in Emacs is implemented by the hide-region-hide command.
I have been using folding-mode for quite some time. With auto-insert template and abrevs it works quite well for me for for some nice bricks of code.
Being able to produce the buffer folded (for printing/emailing) has always been a desire of mine. Some of my folding tags are for secure / password hiding.
I know this is a bit old but for me origami.el works perfectly well out of the box.
Yes Finally code folding is there in emacs. Try yafolding present at melpa.org package library.
I am switching to Emacs from TextMate. One feature of TextMate that I would really like to have in Emacs is the "Find in Project" search box that uses fuzzy matching. Emacs sort of has this with ido, but ido does not search recursively through child directories. It searches only within one directory.
Is there a way to give ido a root directory and to search everything under it?
Update:
The questions below pertain to find-file-in-project.el from Michał Marczyk's answer.
If anything in this message sounds obvious it's because I have used Emacs for less than one week. :-)
As I understand it, project-local-variables lets me define things in a .emacs-project file that I keep in my project root.
How do I point find-file-in-project to my project root?
I am not familiar with regex syntax in Emacs Lisp. The default value for ffip-regexp is:
".*\\.\\(rb\\|js\\|css\\|yml\\|yaml\\|rhtml\\|erb\\|html\\|el\\)"
I presume that I can just switch the extensions to the ones appropriate for my project.
Could you explain the ffip-find-options? From the file:
(defvar ffip-find-options
""
"Extra options to pass to `find' when using find-file-in-project.
Use this to exclude portions of your project: \"-not -regex \\".vendor.\\"\"")
What does this mean exactly and how do I use it to exclude files/directories?
Could you share an example .emacs-project file?
I use M-x rgrep for this. It automatically skips a lot of things you don't want, like .svn directories.
(Updated primarily in order to include actual setup instructions for use with the below mentioned find-file-in-project.el from the RINARI distribution. Original answer left intact; the new bits come after the second horizontal rule.)
Have a look at the TextMate page of the EmacsWiki. The most promising thing they mention is probably this Emacs Lisp script, which provides recursive search under a "project directory" guided by some variables. That file begins with an extensive comments section describing how to use it.
What makes it particularly promising is the following bit:
;; If `ido-mode' is enabled, the menu will use `ido-completing-read'
;; instead of `completing-read'.
Note I haven't used it myself... Though I may very well give it a try now that I've found it! :-)
HTH.
(BTW, that script is part of -- to quote the description from GitHub -- "Rinari Is Not A Rails IDE (it is an Emacs minor mode for Rails)". If you're doing any Rails development, you might want to check out the whole thing.)
Before proceeding any further, configure ido.el. Seriously, it's a must-have on its own and it will improve your experience with find-file-in-project. See this screencast by Stuart Halloway (which I've already mentioned in a comment on this answer) to learn why you need to use it. Also, Stu demonstrates how flexible ido is by emulating TextMate's project-scoped file-finding facility in his own way; if his function suits your needs, read no further.
Ok, so here's how to set up RINARI's find-file-in-project.el:
Obtain find-file-in-project.el and project-local-variables.el from the RINARI distribution and put someplace where Emacs can find them (which means in one of the directories in the load-path variable; you can use (add-to-list 'load-path "/path/to/some/directory") to add new directories to it).
Add (require 'find-file-in-project) to your .emacs file. Also add the following to have the C-x C-M-f sequence bring up the find-file-in-project prompt: (global-set-key (kbd "C-x C-M-f") 'find-file-in-project).
Create a file called .emacs-project in your projects root directory. At a minimum it should contain something like this: (setl ffip-regexp ".*\\.\\(clj\\|py\\)$"). This will make it so that only files whose names and in clj or py will be searched for; please adjust the regex to match your needs. (Note that this regular expression will be passed to the Unix find utility and should use find's preferred regular expression syntax. You still have to double every backslash in regexes as is usual in Emacs; whether you also have to put backslashes before parens / pipes (|) if you want to use their 'magic' regex meaning depends on your find's expectations. The example given above works for me on an Ubuntu box. Look up additional info on regexes in case of doubt.) (Note: this paragraph has been revised in the last edit to fix some confusion w.r.t. regular expression syntax.)
C-x C-M-f away.
There's a number of possible customisations; in particular, you can use (setl ffip-find-options "...") to pass additional options to the Unix find command, which is what find-file-in-project.el calls out to under the hood.
If things appear not to work, please check and double check your spelling -- I did something like (setl ffip-regex ...) once (note the lack of the final 'p' in the variable name) and were initially quite puzzled to discover that no files were being found.
Surprised nobody mentioned https://github.com/defunkt/textmate.el (now gotta make it work on Windows...)
eproject has eproject-grep, which does exactly what you want.
With the right project definition, it will only search project files; it will ignore version control, build artifacts, generated files, whatever. The only downside is that it requires a grep command on your system; this dependency will be eliminated soon.
You can get the effect you want by using GNU Global or IDUtils. They are not Emacs specific, but they has Emacs scripts that integrate that effect. (I don't know too much about them myself.)
You could also opt to use CEDET and the EDE project system. EDE is probably a bit heavy weight, but it has a way to just mark the top of a project. If you also keep GNU Global or IDUtils index files with your project, EDE can use it to find a file by name anywhere, or you can use `semantic-symref' to find references to symbols in your source files. CEDET is at http://cedet.sf.net
For pure, unadulterated speed, I highly recommend a combination of the command-line tool The Silver Searcher (a.k.a. 'ag') with ag.el. The ag-project interactive function will make an educated guess of your project root if you are using git, hg or svn and search the entire project.
FileCache may also be an option. However you would need to add your project directory manually with file-cache-add-directory-recursively.
See these links for info about how Icicles can help here:
find files anywhere, matching any parts of their name (including directory parts)
projects: create, organize, manage, search them
Icicles completion matching can be substring, regexp, fuzzy (various kinds), or combinations of these. You can also combine simple patterns, intersecting the matches or complementing (subtracting) a subset of them
I want to fully-justify latex code on EMACS so that my latex code will look better. For example, I remember my advisor sending me latex in fully justified way like this:
In ~\cite{Hummel2004}, authors described an approach for harvesting
software components from the Web. The basic idea is to use the Web as
the underlying repository, and to utilize standard search engines,
such as Google, as the means of discovering appropriate software
assets. Other researchers have crawled through Internet publicly
available CVS repositories to build their own source code search
engines (e.g., SPARS-J)~\cite{Matsushita2005}.
I suppose that his column-width is set to 70 columns.
Could someone give me a hint?
The standard fill.el package includes the command justify-current-line which is part of what you need. From the function help:
Do some kind of justification on this line.
Normally does full justification: adds spaces to the line to make it end at
the column given by `current-fill-column'.
Optional first argument how specifies alternate type of justification:
it can be `left', `right', `full', `center', or `none'.
If how is t, will justify however the `current-justification' function says to
And other posters have already given you the magicall invokation:
M-x set-justification
As a philosophical side note, the point of fixed-wdith text justification is to fake real typography on a inflexible output device. So applying it to LaTeX source seems a little odd to me. Moreover, I have been using the "one sentence to a line" approach to LaTeX documents for some months now, and find that it really does improves both the editability and the source-control behavior of LaTeX, so I would recommend against doing this.
If you select the region, and then press Ctrl-u M-x fill-region you get "full justification".
M-x set-justification-full
Use Refill mode afterwards to not have to run the command again after typing.
To get line wrap in the file itself (as opposed to something like longlines-mode that does not alter the structure of the file), I use auto-fill-mode, which automatically applies M-q (fill-paragraph) to each paragraph. For example, I use auto-fill-mode in mail-mode. You could do something similar with your LaTeX mode with a hook like this:
(add-hook 'TeX-mode-hook 'turn-on-auto-fill)
Assuming your TeX mode's hook is TeX-mode-hook.