Currently my workflow with Emacs when I am coding in C or C++ involves three windows. The largest on the right contains the file I am working with. The left is split into two, the bottom being a shell which I use to type in compile or make commands, and the top is often some sort of documentation or README file that I want to consult while I am working. Now I know there are some pretty expert Emacs users out there, and I am curious what other Emacs functionally is useful if the intention is to use it as a complete IDE. Specifically, most IDEs usually fulfill these functions is some form or another:
Source code editor
Compiler
Debugging
Documentation Lookup
Version Control
OO features like class lookup and object inspector
For a few of these, it's pretty obvious how Emacs can fit these functions, but what about the rest? Also, if a specific language must be focused on, I'd say it should be C++.
Edit: One user pointed out that I should have been more specific when I said 'what about the rest'. Mostly I was curious about efficient version control, as well as documentation lookup. For example, in SLIME it is fairly easy to do a quick hyperspec lookup on a Lisp function. Is there a quick way to look up something in C++ STL documentation (if I forgot the exact syntax of hash_map, for example)?
You'll have to be specific as to what you mean by "the rest". Except for the object inspector (that I"m aware of), emacs does all the above quite easily:
editor (obvious)
compiler - just run M-x compile and enter your compile command. From there on, you can just M-x compile and use the default. Emacs will capture C/C++ compiler errors (works best with GCC) and help you navigate to lines with warnings or errors.
Debugging - similarly, when you want to debug, type M-x gdb and it will create a gdb buffer with special bindings
Documentation Lookup - emacs has excellent CScope bindings for code navigation. For other documentation: Emacs also has a manpage reader, and for everything else, there's the web and books.
version control - there are lots of Emacs bindings for various VCS backends (CVS, SCCS, RCS, SVN, GIT all come to mind)
Edit: I realize my answer about documentation lookup really pertained to code navigation. Here's some more to-the-point info:
Looking up manpages, info manuals, and Elisp documentation from within emacs
Looking up Python documentation from within Emacs.
Google searching will no doubt reveal further examples.
As the second link shows, looking up functions (and whatever) in other documentation can be done, even if not supported out of the box.
I have to recommend Emacs Code Browser as a more "traditional" IDE style environment for emacs.
EDIT: I also now recommend Magit highly over the standard VCS interface in emacs.
Instead of running a make command in the shell window, have you tried M-x compile? It will run your make command, display errors, and in many cases make it very easy to jump to the line of code that caused the error if the output includes filenames and line numbers.
If you're a fan of IDEs, you might also want to look at emacs' speedbar package (M-x speedbar). And, if you haven't already, learn about how to use tags tables to navigate your code.
There are corners of emacs that once discovered make you more productive in ways you never thought of. As others have mentioned, using tags is a fantastic and fast way to zoom around your source code and using M-/ (dabbrev-expand) often does exactly what you expect when completing a variable name.
Using occur is useful to get a buffer with all occurences of a regular expression in a buffer. That's really handy when refactoring code and looking for fragments of code or uses of variables, or if you use TODO markers in your source files and you want to visit them all.
flush-lines, sort-numeric-fields, replace-regexp and rectangle functions can be really useful for taking a dump from some tool and converting it to useful data such as an elisp program or a comma delimited spreadsheet.
I wrote a page about IDE like things you can do with emacs
http://justinsboringpage.blogspot.com/2007/09/11-visual-studio-tricks-in-emacs.html
Learning elisp is a another great way to answer for yourself what else emacs can do beyond what a typical IDE can do.
For example I've blogged about writing Perforce helper functions like blame (writing your own means you can make it behave exactly as you want)...
http://justinsboringpage.blogspot.com/2009/01/who-changed-line-your-working-on-last.html
I've also written code that dynamically creates comments for a function at point, that matches the coding standards I'm working with.
None of my elisp code is particularly great, and most of it exists already in libraries, but it's really useful to be able to make emacs do custom stuff that just comes up during a working day.
You can find detailed description of emacs & version control integration on my site. I'm also working on article about using Emacs as Development Environment for many languages - C/C++, Java, Perl, Lisp/Scheme, Erlang, etc...
For version control, there are several things that you can use, depending on what version control system you use. But some of the functionality is common to all of them.
vc.el is the built-in way to handle version control at a file level. It has backends for most version control systems. For instance, the Subversion backend comes with Emacs, and there are git backends and others available from other sources.
The most useful command is C-x v v (vc-next-action) that does the appropriate next action for the file you are visiting. This might mean updating from the repository or commiting your changes, vc.el also rebinds C-x C-q to check in and out files if you are using a system that needs it (like RCS).
Other very useful commands are C-x v l and C-x v = that show you the log and current diff for the file you are using.
But for real productivity, you should avoid using the single-file vc.el commands other than for simple things. There are several packages that can give you an overview of the status of your whole tree, and give you more power, and not to mention the ability to create coherent commits spanning several files.
Most of these are heavily influenced or based on the original pcl-cvs/pcvs for CVS. There are even two of them that comes with subversion, psvn.el and dsvn.el. There are packages for git etc.
Okay, everyone here is giving perfect hints to make emacs a great IDE.
But anyone should keep in mind that, when you customize your emacs with a lot of extension (especially with the ones for type-checking on the fly, function definition lookups etc) your emacs will load very, very slow for an editor.
To workaround this, I would highly recommend to use emacs in server mode.
It is pretty simple to use, no need to customize your init file.
You just need to start emacs in daemon mode;
emacs --daemon
This will create an emacs server, then you can connect it either from terminal, or from gui. I'd also recommend to create some aliases to make it easy to call.
alias ec="emacsclient -t"
alias ecc="emacsclient -c &"
# some people also prefer this but no need to fight here;
alias vi="emacsclient -t"
This way, emacs will fire up even faster than gedit, promise.
The one possible problem here, if you are running emacs daemon from your casual user, you probably can't connect emacs server as root.
So, if you need to open a file that has root access; use tramp instead. Just run your emacs client with your normal user and open files like this;
C-x C-f
/sudo:root#localhost/some/file/that/has/root/access/permissions
# on some linux distro it might be `/su:root#...`
This made my life easier, I can open my heavy customized python IDE in miliseconds this way. You may also want to add emacs --daemon to your system startup, or create a desktop file for emacsclient. Thats up to you.
More on emacs daemon and emacs client can be found at wiki;
http://www.emacswiki.org/emacs/EmacsAsDaemon
http://www.emacswiki.org/emacs/EmacsClient
I agree that you should learn about M-x compile (bind that and M-x next-error to a short key sequence).
Learn about the bindings for version control (e.g. vc-diff, vc-next-action, etc.)
Look into registers. You not only can remember locations in buffers but whole window configurations (C-x r w -- window-configuration-to-register).
A starting point (which may be non-obvious) for exploring the VC features of Emacs is M-x vc-next-action.
It does the "next logical version control operation" on the current file, depending on the state of the file and the VC backend. So if the file is not under version control, it registers it, if the file has been changed, the changes are submitted etc.
It takes a little getting used to, but I find it very useful.
Default keybinding is C-x v v
I know this is a very old post. But this question is valid for emacs beginners.
IMO the best way to use emacs as an ide is to use a language server protocol with emacs. You can find all the information about language servers in the linked website.
For a quick setup, i would urge you to go to this page eglot . IMO eglot does it's job pretty well. It integrates well with auto completions packages like company. Provides find reference, and more.
Also for a debugger, you may need specific debuggers for specific languages. You can use gdb from within emacs. Just type M-x gdb .
For compiling your code, it's best to use shell-commands. I am working on this project eproj. It's gonna take a while to complete it. But all it does is maps shell command to project type. And builds you project via shell. It does the same to execute command. I may need help completing this project. It's not ready for use, but if you know a bit of elisp you can go through the code.
That aside, it's always best to use the emacs compile command.
For version control, I haven't yet seen any other package which can match the power of magit. It's specific to git. Also for git there is another package git-timemachine, which i find very useful.
Object lookup and class lookup is provided by language server protocol.
A project tree can be used for ide like interface with treemacs.
There is also a project Interaction Library called projectile.
For auto completion, I find company-mode very useful.
Truly emacs can be made to do anything.
There's a TFS.el for emacs integration into Microsoft TFS. It works with any TFS, including the TFS that runs Codeplex.com.
Basic steps to setup:
Place tfs.el in your load-path.
In your .emacs file:
(require 'tfs)
(setq tfs/tf-exe "c:\\vs2008\\common7\\ide\\tf.exe")
(setq tfs/login "/login:domain\\userid,password")
-or-
(setq tfs/login (getenv "TFSLOGIN")) ;; if you have this set
also in your .emacs file, set local or global key bindings for tfs commands. like so:
(global-set-key "\C-xvo" 'tfs/checkout)
(global-set-key "\C-xvi" 'tfs/checkin)
(global-set-key "\C-xvp" 'tfs/properties)
(global-set-key "\C-xvr" 'tfs/rename)
(global-set-key "\C-xvg" 'tfs/get)
(global-set-key "\C-xvh" 'tfs/history)
(global-set-key "\C-xvu" 'tfs/undo)
(global-set-key "\C-xvd" 'tfs/diff)
(global-set-key "\C-xv-" 'tfs/delete)
(global-set-key "\C-xv+" 'tfs/add)
(global-set-key "\C-xvs" 'tfs/status)
(global-set-key "\C-xva" 'tfs/annotate)
(global-set-key "\C-xvw" 'tfs/workitem)
compile, next-error, and previous-error are all pretty important commands for C++ development in Emacs (works great on grep output too). Etags, visit-tags-table, and find-tag are important as well. completion.el is one of the great unsung hacks of the 20th century, and can speed up your C++ hacking by an order of magnitude. Oh and let's not forget ediff.
I've yet to learn how to use version control without visiting a shell, but now that I'm running commits so much more frequently (with git) I will probably have to.
You might also find tabbar useful. It emulates the only behavior I missed when moving from Eclipse to Emacs. Bound to "," and "." for moving to the previous and next tab bar, it relives you from switching the buffer by Ctrl-x b all the time.
Unfortunately, the mentioned web page does not provide the correct version to download. Most Ubuntu versions, however, deliver it in their emacs-goodies packages.
I use emacs on Windows. the compile module is nice, but I wanted compile to be smarter about the compile command line it suggests. It's possible to use "File Variables" to specify compile-command, but I wanted something a little smarter than that. So I wrote a little function to help out. It guesses the compile command to use, to prompt the user with, when running compile.
The guess function looks for a vbproj or csproj or sln file, and if found, it suggests msbuild. Then it looks at the buffer file name, and depending on that, suggests different things. A .wxs file means it's a WIX project, and you likely want to build an MSI, so the guess logic suggests an nmake command for the MSI. If it's a Javascript module, then the suggestion is to run jslint-for-wsh.js to lint the .js file. As a fallback, it suggests nmake.
The code I use looks like this:
(defun cheeso-guess-compile-command ()
"set `compile-command' intelligently depending on the
current buffer, or the contents of the current directory."
(interactive)
(set (make-local-variable 'compile-command)
(cond
((or (file-expand-wildcards "*.csproj" t)
(file-expand-wildcards "*.vcproj" t)
(file-expand-wildcards "*.vbproj" t)
(file-expand-wildcards "*.shfbproj" t)
(file-expand-wildcards "*.sln" t))
"msbuild ")
;; sometimes, not sure why, the buffer-file-name is
;; not set. Can use it only if set.
(buffer-file-name
(let ((filename (file-name-nondirectory buffer-file-name)))
(cond
;; editing a .wxs (WIX Soluition) file
((string-equal (substring buffer-file-name -4) ".wxs")
(concat "nmake "
;; (substring buffer-file-name 0 -4) ;; includes full path
(file-name-sans-extension filename)
".msi" ))
;; a javascript file - run jslint
((string-equal (substring buffer-file-name -3) ".js")
(concat (getenv "windir")
"\\system32\\cscript.exe c:\\users\\cheeso\\bin\\jslint-for-wsh.js "
filename))
;; something else - do a typical .exe build
(t
(concat "nmake "
(file-name-sans-extension filename)
".exe")))))
(t
"nmake "))))
(defun cheeso-invoke-compile-interactively ()
"fn to wrap the `compile' function. This simply
checks to see if `compile-command' has been previously set, and
if not, invokes `cheeso-guess-compile-command' to set the value.
Then it invokes the `compile' function, interactively."
(interactive)
(cond
((not (boundp 'cheeso-local-compile-command-has-been-set))
(cheeso-guess-compile-command)
(set (make-local-variable 'cheeso-local-compile-command-has-been-set) t)))
;; local compile command has now been set
(call-interactively 'compile))
;; in lieu of binding to `compile', bind to my monkeypatched function
(global-set-key "\C-x\C-e" 'cheeso-invoke-compile-interactively)
I tried doing this as "before advice" for the compile function but couldn't get it to work satisfactorily. So I defined a new function and bound it to the same keystroke combination I have been using for compile.
EDIT there is now "smarter-compile.el" which takes this idea one step further.
In the recent years, Clang became an important part of the Emacs C++ support. Atila Neves had a talk on CppCon 2015:
"Emacs as a C++ IDE"
It is a 16 minute talk, where he shows solutions for the following topics:
Jump to definition
Auto-completion
On-the-fly syntax highlighting
Find file in project
Slides can be found here.
On documentation lookup: that depends on your programming language(s).
C libraries and system calls are typically documented in man pages. For that you can use M-x man. Some things may be documented better in info pages; use M-x info.
For elisp itself, use C-h f. For python, use >>> help(<function, class, module>) in the interpreter.
I find that most other languages offer documentation in html form. For that, try an embedded browser (I use w3m). Set your BROWSER environment variable to a wrapper script around emacsclient -e "(w3m-goto-url-new-session \"$#\")" (on *nix), in case something might open a browser and you want it opened inside emacs.
Try lsp-mode. Now you can use other IDE functionality inside emacs connecting to server. Look for more info: lsp-mode
In the Unix or X windows style, I don't know that there is an integrated IDE that works for everything.
For interacting with debuggers, just one component of an IDE, consider realgud. The other thing it has that I find useful are parsers for location messages, so that if you have a call stack trace and want to edit at a particular place in the callstack, this front-end interface will can do that.
By far this program could use improvement. But then it could also use people working on it to improve it.
Disclaimer: I work on realgud
Related
After installing pdf-tools the dired mode opens the pdf file with PDFView mode as major mode.
(use-package pdf-tools
:ensure t
:config
(pdf-tools-install t))
How does the pdf-tools package be able to accomplish this?
The Help for RET key in dried buffer says it is bound to dired-find-file
RET (translated from ) runs the command dired-find-file (found
in dired-mode-map), which is an interactive compiled Lisp function.
I searched for dired-find-file in pdf-tools installed elisp files and could not find any advice-add's?
Also please explain how can one go about finding arbitrary key bindings like this one?
What it modified is not directly related to dired, but to how Emacs decides to open files in general. The part of the code that is responsible for that is in pdf-tools-install-noverify, itself called by pdf-tools-install. The first two lines of the function are:
(add-to-list 'auto-mode-alist pdf-tools-auto-mode-alist-entry)
(add-to-list 'magic-mode-alist pdf-tools-magic-mode-alist-entry)
the relevant variables pdf-tools-<auto/magic>-mode-alist-entry being constants defined earlier in the file pdf-tools.el.
You can check the relevant documentation for auto-mode-alist and magic-mode-alist, but to sum up, the former is a mapping from "filenames" (or more precisely, file patterns -- typically, regexps matching file extensions) to major modes, and the latter is a mapping from "beginning of a buffer" to a major mode (see also this wikipedia page on magic numbers/file signatures).
As to how one can determine that: because it is not directly related to key bindings/advices/redefinition of functions, the only "general" option is to explore the "call stack" ! The package tells you to put (pdf-tools-install) somewhere in your init file to activate the package, so you can try to see what this function actually does -- and going a bit further, you see that it is essentially a wrapper around pdf-tools-install-noverify, which does the real job of setting everything up.
EDIT I've also asked this question on emacs.stackexchange
I'm a relative emacs newbie and have set up my emacs (24.4.1) to work with clojure as described here.
The gist of it is that I am now using the latest org-mode from git and loading it in my init.el (I am using prelude btw) as below:
(add-to-list 'load-path "~/repos/org-mode/lisp")
(require 'org)
(require 'ob-clojure)
I am trying to use org to write a literate clojure program that I can export to markdown. Clojure and babel now work well, evaluation works etc, but when I try to export my org file I get an error.
load-with-code-conversion: Symbol's value as variable is void: p
The stack trace when I set toggle-debug-on-error is:
Debugger entered--Lisp error: (void-variable p)
eval-buffer(#<buffer *load*> nil
"/Users/krisfoster/repos/org-mode/lisp/ox.el" nil t)
; Reading at buffer position 229233
load-with-code-conversion("/Users/krisfoster/repos/org-mode/lisp/ox.el"
"/Users/krisfoster/repos/org-mode/lisp/ox.el" nil t)
autoload-do-load((autoload "ox" "Export dispatcher for Org mode.\n
\nIt provides an access to common export related tasks in a
buffer.\nIts interface comes in two flavors: standard and
expert.\n\nWhile both share the same set of bindings, only the
former\ndisplays the valid keys associations in a dedicated
buffer.\nScrolling (resp. line-wise motion) in this buffer is done
with\nSPC and DEL (resp. C-n and C-p) keys.\n\nSet variable `org-
export-dispatch-use-expert-ui' to switch to one\nflavor or the
other.\n\nWhen ARG is \\[universal-argument], repeat the last
export action, with the same set\nof options used back then, on
the current buffer.\n\nWhen ARG is \\[universal-argument] \\
[universal-argument], display the asynchronous export
stack.\n\n(fn &optional ARG)" t nil) org-export-dispatch)
command-execute(org-export-dispatch)
I tried to resolve this by (require-ing the various org export packages, the ones in the clone of the org git repo that is, from within my init.el. But no dice - in fact that generated yet more issues. I have tried debugging but can't figure out what is wrong. I am suspecting I need to be requiring something but don't know what.
I have my init.el here - init.el gist
Any-one have any ideas what I am doing wrong?
Thanks in advance.
There was a bug in org-mode around the time you made this post, so the problem may be resolved. However, I noticed a few issues with your init file. Some things which might help
Use the lisp package manager to install your packages (ELPA). This will make your life much easier. The org guys maintain an ELPA repository which is updated regularly and will likely be a little more stable than just pulling in the repo. They have a version called org-plus-contrib which I use and find quite good. Just add
(add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/"))
You state that your running prelude, but I can't see anything in your init which is loading prelude (only a call to a function which turns off the guru-mode). Prelude is pretty good and quite popular, but if your going to use it, you need to 'drink the cool aid' that is, do things in the prelude way. For example, prelude comes with org-mode and uses ELPA to install it. You need to be careful your not get a blend of org versions. Another alternative to prelude which I found very good is Steve Purcell's emacs.d. I found it a little easier to work with YMMV, but it may be worth checking out as it has good support for the mac. See emacs.d
It is a really good idea to break up your emacs init script into separate files. This makes it easy to comment out lots of stuff when your trying to track down a problem and allows you to just focus on the key bits your trying to get working. I maintain my init.el file as an org file and use babel to generate all the lisp code. You can have a look at it on github. I originally started with Purcell's emacs.d and then borrowed with pride (stole) much of it to go into my own config. It isn't a fine example of how to configure emacs, but might help with your setup
I notice your attempting to use cider as the backend 'evaluator' for clojure code. Note that you only need to do this if you want to have blocks of clojure in your org file which you want to evaluate and then use the result. You don't need to do this if all you want to do is generate *.clj files from your org code. Instead, you just want to 'tangle' your org file, which will generate the updated clj source files, which you can then work on. This keeps things a lot simpler and avoids problems arising when you try to do things with your org file that attempt to evaluate the clojure code and fail. Note also that I expect you would need to do a bit more than just set cider as the backend evaluator - cide is just an interface to a repl. You would need a repl as well.
I'm trying to get doremi working in emacs. Specifically, at this stage, to allow me to quickly scroll through a condensed list of color-themes and see each theme as I go through it. For this I would use the 'M-x doremi-color-themes+' command.
What I've done:
Installed color-themes (successfull)
Installed doremi.el, doremi-cmd.el, ring+.el and added
(add-to-list 'loadpath "~/elisp/themes")
(add-to-list 'loadpath "~/elisp/doremi/")
(require 'color-theme)
(color-theme-initialize)
(color-theme-classic)
;; create a list of color themes to scroll through using 'doremi-cmd
(setq my-color-themes (list 'color-theme-classic
'color-theme-retro-green
'color-theme-gray30
'color-theme-subtle-hacker
'color-theme-jonadabian-slate))
(require 'doremi)
(require 'doremi-cmd)
(require 'ring+)
to the .emacs file.
What emacs does:
When I type the comand 'M-x doremi-color-themes+' into the mini-buffer it seems to accept that I've given it a valid command and tells me to use the and arrow keys to move through the list. But when I do that all that happens is the cursor moves up and down in the active window. No changing of color-themes.
Being somewhat new to emacs (and especially customising it) I'm sure I have missed a step or put something in the wrong place. Perhaps there's some sort of (setq 'bla-bla-bla (...)) I need to do?
Sorry for your trouble. Please state your Emacs version (M-x emacs-version), and your version of color-theme.el.
You do not need to require library ring+.el if you use Emacs 23 or later (its code was included in GnuEmacs 23.)
You do not need to use (color-theme-initialize) or (color-theme-classic). The former is done automatically by doremi-color-themes+.
Try starting from emacs -Q (i.e., no init file, ~/.emacs), to be sure there is no interference from stuff in your init file.
Your variable my-color-themes is not referenced anywhere. Instead of defining that variable, just customize user option doremi-color-themes. (Or leave its value nil, which means that all color themes will be cycled through.)
Feel free to contact me by email if you continue to have a problem. Or continue here, if you prefer.
[Just to be sure: you are using color-theme.el, right? There is a lot of confusion out there between Emacs "custom themes" and color themes. Do Re Mi supports both, but they are different critters.]
After a bit for back and forth with #Drew we found a solution to the problem.
It turned out the major problem was that I was using emacs in 'terminal mode' rather than as a GUI application. Bare in mind I'm using a mac.
In the context of Terminal, my arrow keys send escape sequences and so doremi cannot read the event as intended. So it just escapes and applies the message to the active buffer.
There is an answer.
By adding the following lines to my .emacs file (or whatever your init file for emacs is) I was able to redirect doremi to use two other keys. ie. not the up and down arrows.
(setq doremi-down-keys '(?n))
(setq doremi-up-keys '(?p))
Doing this tells doremi to use 'n' as the down key and 'p' as the up key. And all works just fine.
Because I am only new to the world of programming and computing I may often use incorrect terminology. If this is the case please let me know and I will edit accordingly for clarity and consistency.
Hi I work on a very large and complex C code base (complex not in a good way). The codebase dwarfs the linux kernel to give you an idea. I have set up emacs to do most of what I want. I get autocompletion on functions and variables but there are certain things which do not work (omni-completion).
I use cedet v2, xgtags, auto-complete, yastnippet, cscope and a few other tools all of which are installed via el-get on emacs-24. When I work on a smaller project, omni-completion in C works so I would get a list of the members of a struct when I access the object. However, in the very large "project", omni-completion does not work when accessing a struct. As I said, I get completion on functions and variables but not on structures.
My explanation is that auto-completion is using its parser which cannot handle the size and complexity of the codebase. However, gtags or etags can handle it.
Is there a way to make auto-complete look into the gtags (xgtags) database? My gtags are working very well indeed.
EDIT:
I am not an admin on my system and I cannot install packages easily. At the moment, I do not have clang. Having said that, I am quite capable of compiling from source and can get many packages this way.
Using clang+automplete is also an option:
http://truongtx.me/2013/03/06/emacs-ccpp-autocomplete-with-clang/
Edit: I see you've edited the question indicating you have no clang. I leave this answer here regardless, in case someone else finds it useful.
Have you tried ac-source-gtags that is comes together with auto-complete package? You can also combine several sources, like described in documentation...
I have found that cedet is really underwhelming.
I would recommend using just one tool which does everything
https://github.com/Andersbakken/rtags
It underlines errors as you type as well as using smart completions. Just add this to your init file after obtaining the required emacs packages
(require 'rtags)
(require 'popup)
(require 'rtags-ac)
(setq rtags-completions-enabled t)
(rtags-enable-standard-keybindings c-mode-base-map)
(add-hook 'c++-mode-hook
(lambda ()
(setq ac-sources '(ac-source-rtags)
)))
Last week, infuriated (again) by having to cope with different IDEs for R and Perl, neither of which I like or use enough to get really comfortable in, I decided to try Emacs. This decision was not made without a certain trepidation on my part. My main use is for Perl with cperl and for R with ESS. My environment is Windows 7 Ultimate 64-bit and I am running v23.4.1, which I think is what the ESS package installed on my behalf.
Nearly a week in and so far it has been surprisingly painless, no more involved than any other significant piece of software. I have remapped my ctrl key to caps-lock, changed default folders, messed around with .emacs and made some additions such as auto-install, yasnippet, color-theme, icicles and a few others. Clearly there is some very sophisticated stuff out there. In addition of course certain features of base Emacs are immediately very powerful and useful, such as isearching up and down. On the whole I have been pleasantly surprised and reassured.
One thing that is cruder than I was expecting is the process of finding and opening files. After a cursory read of various tutorials I had this image of quasi-magical file location and filename auto-completion. The main directories in my setup have paths like g:/roaming/code/perl or g:/roaming/code/R/ but I often need to branch into completely different paths like g:/pricedata/support files/sector/project01/ and so on.
Currently I laboriously delete the file path when I need to take a different fork, then use auto-complete to move deeper into that branch of the filesystem. It kinda takes me back to running a bash shell on the Amiga twenty years ago.
What had I expected? Something like (using the above example) typing 'project01' to skip immediately into the folder at the bottom of the path. For some reason I had got the idea in my head that Emacs would preload directories. So maybe this wasn't realistic.
My guess is that my difficulties probably stem from my own lack of familiarity rather than a structural shortcoming in Emacs and leads on to my questions. I can't complain that there is not enough documentation; rather there is abundant information that it is scattered around rather haphazardly. Icicles has a similar problem - if anything there's too much.
1) What is the best tactic for moving around different branches of the file tree when trying to open files in the minibuffer or using some other method? Are there aliases that can be used to shortcut from one place to another or can one specify directories to be preloaded? Do people just cd around a lot? Or am I coming at this from completely the wrong angle and need to adopt a different strategy?
2) With additional setup, can auto-complete be used to find files in (say) the project01 directly above by prefixing with wildcards etc? What should I focus on to become more efficient here? Am I not tapping the power of add-ons like icicles, anything etc?
I realise these questions veer dangerously close the deprecated category of not having clear answers. My defence is that some tips/guidance at this stage before I commit myself to bad habits or a poor long-term solution would be welcome and I suspect the answers will benefit others who might be considering the switch. I am happy to withdraw or rephrase if there are problems.
helm (formerly known as anything) might suit you. You can install it manually, or using a auto-install extension.
For the auto-install way: download it, put in Your load-path, then add to .emacs:
(add-to-list 'load-path "~/.emacs.d/site-lisp/auto-install")
(require 'auto-install)
(setq auto-install-directory "~/.emacs.d/site-lisp/auto-install/")
Then do M-x auto-install-batch anything. After that is done, put in .emacs:
(require 'anything)
(require 'anything-match-plugin)
(require 'anything-config)
(require 'anything-show-completion)
Then do M-x anything for anything.
Also give a try to ECB (stands for Emacs Code Browser). If you're on Linux, you probably have it available in a standard repository.
You could benefit from using ido-mode, which greatly enhances autocompletion nearly everywhere in emacs (especially when finding files or buffers)
(setq ido-enable-flex-matching t
ido-auto-merge-work-directories-length -1
ido-create-new-buffer 'always
ido-use-filename-at-point 'guess
ido-everywhere t
ido-default-buffer-method 'selected-window)
(ido-mode 1)
(put 'ido-exit-minibuffer 'disabled nil)
(when (require 'ido-ubiquitous nil t)
(ido-ubiquitous-mode 1))
While this might help you quickly finding files "not far away", it probably won't help you much finding files in entirely different locations.
If find that one way to begin tackling this problem is using recentf-mode to quickly jump to recent locations (if you have only a small number of usual project directories, this might do the trick). recentf can be coupled with ido using something like this (I'm not sure where I got this snippet from):
(recentf-mode 1)
(setq recentf-max-saved-items 50)
(defun ido-recentf-open ()
"Use `ido-completing-read' to \\[find-file] a recent file"
(interactive)
(if (find-file (ido-completing-read "Find recent file: " recentf-list))
(message "Opening file...")
(message "Aborting")))
(global-set-key (kbd "C-x C-r") 'ido-recentf-open)
With this, you can use C-x C-f (ido-find-file) to look for files near you current location, and C-x C-r (ido-recentf-open) to look for recently opened files (hoping one of them is not too far away from where you want to go).
There are various approaches. File name cache is a built in solution. Opening files from recent files is also very effective, especially if you set the stored files to a high number (e.g. 1000). There are also packages for opening files from anywhere on the file system. And there are meta solutions like anything.el which can show you file completions from multiple sources (history, project files, etc.) in a common interface.
You should investigate the different options to find out which is the most suitable for you.
In addition to IDO and recetf you can use the following methods:
Open the directory recursively.
(defun op-i:dired (rec)
"customized dired: will display directory recursively when called with an argument"
(interactive "P")
(let ((dir (car (find-file-read-args "Dired: " nil)))
(opts (if rec (read-string "options: " "-lhAR") "-lhA")))
(if (file-directory-p dir) (dired dir opts))))
(define-key (current-global-map) (kbd "C-x C-d") 'op-i:dired)
Then you can navigate in the directory buffer as in any other buffer using a (wildcard) search.
Use Emacs registers to point to often used directories. You can initialize them in your .emacs
(set-register ?0 (cons 'file "c:/path/to/my-project0"))
(set-register ?1 (cons 'file "c:/path/to/my-project1"))
Then jump to register using C-x r j
Other people have already mentioned anything, suffice it to say, I believe it solves all your problems. :)
Calling out one specific feature of anything is anything-locate. On *nix systems, this uses the DB created by the locate command to quickly find files. On Windows, I believe it works with "Everything", which should give you near instantaneous search results across all your files. I mean all.
Tom has mentioned file-cache. Anything works with that.
Just as a side note, Dired is an absolute monster once you get used to it. You should read the emacswiki pages related to it. In particular dired-x, which comes with Emacs binds C-x C-j, jumps to current buffer in Dired was a revelation for me. Also dired-find, wdired.
Edit: some details on why C-x C-j is awesome.
When you pop the current buffer in a Dired buffer, you can modify it, i.e. rename, delete, etc. And Emacs is aware of what you've done, and adjusts accordingly.
Other possibilities:
Bookmarks. If you use Bookmark+ then you can also:
Bookmark Dired buffers, which remembers their inserted subdirs, their markings, and their file omissions. You can have a bookmark that opens Dired to a specific set of files that need not be in the same directory or even the same directory tree.
From Dired you can hit a key to create a separate bookmark to each marked file or subdir.
Bookmark files automatically (autofiles).
Tag bookmarks and files (autofile bookmarks) with arbitrary-text tags. (Tags can even be non-text Lisp objects). Use tags to organize, search, etc. different categories of bookmarks.
Bookmark sets of bookmarks or bookmark files or Emacs desktops. Jump to such a bookmark to restore a given project state/context.
Icicles.
Define temporary or persistent sets of files on the fly, even from different directories. Operate on the files in a set in various ways. (Use Emacs filesets, less powerful, the same way.)
Complete against file names from such saved sets during any completion command, not just file-finding.
Act in different ways on candidate files during completion.
Search bookmarked objects or saved sets of files or buffers.
Dired+.
Additional navigation, including i bouncing between a subdirectory listing and the subdirectory's line in the parent listing.
Refs:
http://www.emacswiki.org/cgi-bin/wiki/BookmarkPlus
http://www.emacswiki.org/emacs/Icicles_-_Support_for_Projects
http://www.emacswiki.org/emacs/Icicles_-_File-Name_Input
http://www.emacswiki.org/cgi-bin/wiki/DiredPlus