Next: , Previous: Programming Aids, Up: Programming Aids

2.1 Cross-Referencing (Tags)

A “dynamic tags” facility effectively makes each function call in an Erlang source file into a hyperlink to the definition of that function. For example, if you have a line of code like this:

     lists:keysort(2, L).

You can place the point on the function name, press M-., and up pops lists.erl at the definition of keysort/2. After you have perused the definition to your satisfaction, you press M-, to jump back where you came from. You can also jump through several (sub)function definitions and then use M-, several times to unwind step-by-step back to where you came from.

This feature is a dynamic version of a traditional Emacs facility called “Tags.” Whereas Tags needs you to maintain a special TAGS file to keep track of definitions, Distel simply asks an Erlang node, “Where is the source file for module foo?” The Erlang node makes a well-educated guess at which source file we want (based on the location and attributes of the beam file for the same module), and sends back the path. Emacs then opens the file and scans down to the definition of the function with the right arity.

If you have several versions of the same source file (perhaps belonging to separate branches in revision control), then Distel will find the one that matches the code in the Erlang node you're talking to. So, to work on a particular source tree you just connect to a node that has the matching code in its code path.

Jump from a function call to the definition of the function (erl-find-source-under-point). If the variable distel-tags-compliant is non-nil, or a prefix argument is given, this command prompts for the function name to lookup.
Jump back from a function definition (erl-find-source-unwind). This is a multi-level unwind through a stack of positions from which you have jumped with M-. The command is also bound to M-* for consistency with “etags.”

To actually find the source file for a particular module, the Erlang node first ensures that it can load the module, and then tries each of these locations in order:

  1. Same directory as the beam file.
  2. ../src/ from the beam file.
  3. ../erl/ from the beam file.
  4. The directory from which the beam file was compiled. We can find this using module_info/1, because the compiler records it as an attribute in the beam file.