Last edit
Sumário: Fixed a typo.
Alterado:
< These needs are especially important when calling library code written by somone else and stored in include/ and lib/ outside my project.
para
> These needs are especially important when calling library code written by someone else and stored in include/ and lib/ outside my project.
In brief:
These needs are especially important when calling library code written by someone else and stored in include/ and lib/ outside my project.
Let us explain those needs one by one.
Suppose I write the name of an object and then the dot:
my_class my_object; my_object.
Of course, now I will probably want to write the name of a member function (or variable) declared as public in class my_class.
Now there are some main things to point out:
Usually, I can’t remember the names of the members of my_class. For instance, I never remember whether it is string::size() or string::length(). :-)
Let me repeat that:I do not usually know the name of the member I am calling. I do know its semantics, but I don’t know its name. Very often, I presume to know the name, but I am not sure of that name, and I need a confirmation.
Of course :
I need some kind of assistance: a tool which knows my code better than me, and which can promptly remind me the names of the class members.
Notice there are two distinct situations where I need such a reminder:
A C++ programmer which uses such a reminder feature essentially repeats the following process thousands of times:
0. Precondition: I have typed the name of the object, then the dot, but I can’t remember the name of the member I must write; I just presume it is called “size()”, but it might as weel be “length()”. I need a confirmation.
1. I press some key to get the list of possible member names; The list should appear in a separate window (without hiding the source code).
2. I read the list and locate the name I had in mind. If it’s not there, I find the correct one.
3. (Now I know the name I want to type:)
Actually, the above scheme is too optimistic: point 2 is often impossible to do, because the list is often too long to be read! For example, take std::string: there are a hundred items (counting functions, variables, typdefs, enums). So the above process should be rewritten as follows (notice that point 2 has been expanded into two points: 2.1 and 2.2):
0. Precondition: I have typed the name of the object, then the dot, but I can’t remember the name of the member I must write; I just presume it is called “size()”, but it might as weel be “length()”. I need a confirmation.
1. I press some key to get the list of possible member names; The list should appear in a separate window (without hiding the source code).
2.1 while (the list is too long to be read):
2.2. (Now the list is narrow enough for you to read, and I have written zero or more letters of the member’s name).
3. (Now I know the name I want to type, and the list displays only a few members)
After typing the function name and open parenthesis, show the list of arguments (name and type). In C++ there may be multiple definitions with the same function name (overloading), so it would be necessary to show all possible matches.
To be written.
For C++ and other languages that have the concept of a member function: be able to find and display in some new window or buffer all callers of the member function under point. Note that this should not list all member functions of that name, so it should be able to sense the context. Oh, and it must not get confused by preprocessing directives and macros!!
When I change a file and save it, and then want to locate a symbol (class, type, variable, member function, etc. etc.) don’t make me wait for the code parser/scanner thingy to reparse every file in the project. See CScopeAndEmacs for info on cscope that does allow locating symbols in large filesets, but forces you to wait for it to rebuild its entire symbol database each time it detects a change to a single file.
Should be significantly faster than grepping the entire source code tree. Threshold of waiting should be < 1 second. For initial parsing of the tree, that would of course take longer, but once it is done, lookup operations should not take longer than 1 second to find symbols.
5 million lines is a start.