want to feel the power of rope try its features and see its unit
-Note that the keys mentioned in this file are the ones that are used
+This file is more suitable for the users. Developers that plan to use
+rope as a library might find library.txt_ more useful.
+Most of this document was written before breaking rope and ropeide
+into two separate projects. That's why some parts of this file
+specifically talks about ropeide_. Also most of the keys mentioned in
+this file are the ones that are used in ropeide_ but ropemacs_ uses
+similar keys most of the time.
.. contents:: Table of Contents
+.. _ropeide: http://rope.sf.net/ropeide.html
+.. _ropemacs: http://rope.sf.net/ropemacs.html
+.. _library.txt: library.html
* There is a ``config.py`` file in this folder in which you can change
project configurations. Have look at the default ``config.py`` file
(is created when it does not exist) for more information. (``C-x p
- c`` open this file automatically in ropemacs or ropeide).
+ c`` open this file automatically in ropemacs or ropeide).
* It can be used for saving project history, so that the next time you
open the project you can see and undo past changes. (see ``project
* It can be used for saving object information to help rope object
* It can be used for saving global names cache which is used in
You can tell rope to rename all occurrences of a name in comments and
-strings. This can be done in rename refactoring dialog by selecting
-its radio button or by passing ``docs=True`` to `Rename.get_changes()`
-method when using rope as a library. Rope renames names in comments
-and strings only where the name is visible. For example in::
+strings. This can be done in rename refactoring dialog of ropeide_ by
+selecting its radio button or by passing ``docs=True`` to
+`Rename.get_changes()` method when using rope as a library. Rope
+renames names in comments and strings only where the name is visible.
This makes it safe to assume that this option does not perform wrong
renames most of the time and for this reason it is on by default in
-the ropeide (though not in `Rename.get_changes()`).
+the ropeide (though not in `Rename.get_changes()`).
This also changes occurrences inside evaluated strings::
-In the change method signature dialog these shortcuts work:
+In the change method signature dialog (for ropeide_) these shortcuts
Some refactorings might take a long time to finish (based on the size
-of your project). Rope now shows a dialog that has a progress bar and
-a stop button for these refactorings. You can also use this feature
-when using rope as a library. The `get_changes()` method of these
-refactorings take a new parameter called `task_handle`. If you want
-to monitor or stop these refactoring you can pass a `rope.refactor.
-taskhandle.TaskHandle` to this method. See `rope.refactor.taskhandle`
-module for more information.
+of your project). Ropeide_ shows a dialog that has a progress bar and
+a stop button for these refactorings (ropemacs uses something similar,
+also). You can also use this feature when using rope as a library.
+The `get_changes()` method of these refactorings take a new parameter
+called `task_handle`. If you want to monitor or stop these
+refactoring you can pass a `rope.refactor. taskhandle.TaskHandle` to
+this method. See `rope.refactor.taskhandle` module for more
Basic Implicit Interfaces
For performing this refactoring using rope library see `library.txt`_.
-.. _library.txt: library.html
Here the objects `a_var` and `c` hold are known.
-Another thing that has been added is SOI analysis (Available in
-``Edit`` menu or by using ``C-c x s``). It analyzes a module for
-finding useful object information. Rope runs SOI analysis whenever a
-files is changed on the changed scopes automatically. (This can be
-overridden in project ``config.py``.)
+SOI analysis (``C-c x s`` in ropeide_) analyzes a module for finding
+useful object information. Rope runs SOI analysis whenever a files is
+changed on the changed scopes automatically. (This can be overridden
+in project ``config.py``.)
Many kinds of information is collected during SOI like per name data
for builtin container types::
running SOI analysis on this module.
You might be wondering is there any reason for using DOI instead of
-SOI. The answer is that DOI is more accurate and handles complex and
-dynamic situations. For example in::
+SOI. The answer is that DOI might be more accurate and handles
+complex and dynamic situations. For example in::
SOI can no way conclude the object `a_var` holds but it is really
trivial for DOI. What's more SOI analyzes calls only in one module
while DOI analyzes any call that happens when running a module. That
-is for achieving the same result as DOI you might need to run SOI on
+is for achieving the same result as DOI you might need to run SOI on
more than one module and more than once (not considering dynamic
situations.) One advantage of SOI is that it is much faster than DOI.
Dynamic type inference collects its information by running modules
-(``C-c x p``) or unit tests (``C-c x t``). Since as the program runs,
-rope gathers type information, the program runs slower. Right now
-rope doesn't have a good interface for running programs. It just
-prints the output to the terminal and does not get inputs. This will
-be enhanced in future releases. After the program is run, you can get
-better code assists and some of the refactorings perform much better.
+(``C-c x p`` in ropeide_) or unit tests (``C-c x t`` in ropeide_).
+Since as the program runs, rope gathers type information, the program
+runs slower. Right now rope doesn't have a good interface for running
+programs. It just prints the output to the terminal and does not get
+inputs. This will be enhanced in future releases. After the program
+is run, you can get better code assists and some of the refactorings