El dt, abr 14 2009, Eric M. Ludlam va escriure:
>
>>3. It could be useful also to highlight functions; for instance:
>> p.drawEllipse( 3, 3, 10, 10);
>> p.drawEllipse(33, 3, 10, 10);
>> p.drawEllipse(18, 18, 10, 10);
>>
>> If you hover one drawEllipse, the others 2 will be highlighted,
>> because it is the same symbol. Other editors also do this.
>
> There may be a bug. For example, if you put the cursor on the
> drawEllipse, does it provide a summary? If not, it cannot highlight
> it either, as it would try to distinguish p.drawEllipse from
> q.drawEllipse, where q is not the same type as p.
>
>>4. Actually, IDEs like Eclipse would highlight the 3 of them,
>>including the current one. This can aid in counting occurrences
>>specially when you have started scrolling up and down and you have
>>lost track of where the cursor was. In Emacs, where the cursor jumps
>>while you scroll, I don't know how useful would it be.
>>
>>5. Occurences of the same global variable are not highlighted; for instance:
>> void BasePointWidget::paintEvent(QPaintEvent *e){
>> QPainter p;
>> p.begin(this);
>> p.setRenderHint(QPainter::Antialiasing, true);
>> p.setBrush(palette().color(QPalette::Window));
>> if (m_mode == 0)
>> {
>> p.drawEllipse( 4, 4, 10, 10);
>> }
>> p.setPen(QPen(palette().color(QPalette::WindowText), 2));
>> if (m_mode == 0)
>> { p.drawLine(8, 8, 33, 8); p.drawLine(8, 38, 33, 38); }}
>> {
>> p.drawLine(7, 7, 32, 7);
>> p.drawLine(7, 37, 32, 37);
>> }}
>>
>> m_mode won't be highlighted. p will be.
>
> Again, check to see of the analyzer can find m_mode at all. For a
> detailed analysis, use
>
> M-x semantic-analyze-debug-assist
>
> while on the offending symbol.
>
To test this I used the Subversion code of Scribus, file basepointwidget.cpp, around line 50:
QPainter p;
p.begin(this);
p.setRenderHint(QPainter::Antialiasing, true);
p.setBrush(palette().color(QPalette::Window));
p.setPen(Qt::NoPen);
p.drawRect(0, 0, width(), height());
p.setBrush(Qt::black);
p.setPen(QPen(palette().color(QPalette::WindowText), 1));
if (m_mode == 0)
{
p.drawEllipse( 4, 4, 10, 10);
p.drawEllipse(34, 4, 10, 10);
p.drawEllipse(19, 19, 10, 10);
p.drawEllipse( 4, 34, 10, 10);
p.drawEllipse(34, 34, 10, 10);
}
I stepped over drawEllipse and did semantic-analyze-debug-assist (what a useful function!).
And I got:
-----------------------------------------------
Unable to find datatype for: "class QPainter p".
Declared type is: "class QPainter {}"
Raw data type is: ("QPainter" type (:type "class") nil nil)
Semantic could not find this data type in any of its global tables.
Semantic locates datatypes through either the local scope, or the global
typecache.
Local Scope Information:
* Tag Class Constraint against SCOPE: (type)
* No known parents in current scope.
* No known symbols currently in scope.
* No known symbols declared locally.
Semantic creates and maintains a type cache for each buffer.
If the type is a global type, then it should appear in they typecache.
To examine the typecache, type:
M-x semanticdb-typecache-dump RET [ Do It ]
Current typecache Statistics:
0 types global in this file
0 types from includes.
If the datatype is not in the typecache, then your include
path may be incorrect.
Include Path Summary:
The system include path is:
/usr/include/
/usr/include/c++/4.3.3/
/usr/include/c++/4.3.3/i486-linux-gnu/
/usr/include/c++/4.3/
/usr/include/c++/4.3/i486-linux-gnu/
Include Summary: /home/dc/suma/nb/toma2/oficial/scribus/basepointwidget.cpp
basepointwidget.cpp contains 1 includes.
Unknown Includes: 0
Unparsed Includes: 0
Parsed Includes: 1
A likely cause of an unfound tag is missing include files.
The following includes were not found:
QPainter
QMouseEvent
QPaintEvent
QWidget
You can fix the include path for c++-mode by using this function:
M-x semantic-customize-system-include-path RET [ Do It ]
which customizes the mode specific variable for the mode-local
variable `semantic-dependency-system-include-path'.
[back]
-----------------------------------------------
This may be simply because CEDET doesn't know about the Qt3 includes (QPainter, QMouseEvent, ...).
This is probably due to my project configuration; basically: I haven't configured anything yet. I must still learn about projects in Emacs/CEDET/EDE/JDE/….
As a user my expectations would be:
1. CEDET itself could parse the Makefile and get all these project settings; if that works, it's wonderful. No configuration needed.
2. If something does not work because I must configure a project, I want to get warnings from time to time to know that things are broken. For instance if I step over a symbol which could not be parsed due to project misconfiguration.
Or, like Eclipse does, with another face for things that could not be correctly parsed (including types not found).
-- Daniel
|