Hi,
tonight I wrote small patch that adds functions arguments to autocomplete:
(http://i.imgur.com/ePWg0.png?1)
As you can see types and return value will be removed.
I modify src/plugins/codecompletion/codecompletion.cpp and src/sdk/wxscintilla/src/scintilla/src/ScintillaBase.cxx
Maybe it will be useful for someone, so enjoy.
(I hope this is good section for posting patches?)
Looks good, I'll test tomorrow :)
Question: Why you hack the scintilla code? ;)
PS: should be posted/moved to CodeCompletion redesign (http://forums.next.codeblocks.org/index.php/board,18.0.html)
ollydbg: I thought that scintilla is only place that can I modify selected text, but I was wrong. Now I see that I should insert this code in EditorEventHook. I forgot about wxEVT_SCI_AUTOCOMP_SELECTION event. I'll fix it later.
Quote from: p2rkw on November 26, 2012, 04:03:48 AM
Now I see that I should insert this code in EditorEventHook. I forgot about wxEVT_SCI_AUTOCOMP_SELECTION event. I'll fix it later.
Definitely. wxScintilla should not be touched for such reasons.
Ok, I attach corrected patch. Please test it. After patching autocomplete will insert default argument names, so if you want back to old behaviour set 'autoAddArgsNames' to false (line 1507 in codecompletion.cpp).
Quote from: p2rkw on November 26, 2012, 03:54:00 PM
Ok, I attach corrected patch. Please test it. After patching autocomplete will insert default argument names, so if you want back to old behaviour set 'autoAddArgsNames' to false (line 1507 in codecompletion.cpp).
Although the functionality might be interesting, please follow our general coding lines.
So (for example) don't add method names with a lower letter, don't add global static functions which can be private to the class and so on... Otherwise the code starts to become really messy and this is not what we want.
Quote from: MortenMacFly on November 26, 2012, 08:15:08 PM
...don't add global static functions which can be private to the class and so on...
I don't agree here, global static function are way more private then a private function in the class. I tend to use them a lot.
I forgot about capital letters, sorry,
I made those 3 functions as static free functions because they don't touch any Codecompletion's non-static and static fields. Moreover they're visible only in codecompletion.cpp compilation unit.
Nice idea, but how do you deal with really long call sigs? Would be nice if the box was horizontally scrollable but that probably requires changes to scintilla. Also, would be really nice to have a second pane that shows doc strings. (see Netbeans (http://netbeans.org/features/ide/editor.html))
Quote from: p2rkw on November 26, 2012, 08:33:47 PM
I made those 3 functions as static free functions because they don't touch any Codecompletion's non-static and static fields. Moreover they're visible only in codecompletion.cpp compilation unit.
Then put them on top of the unit into a "Helper" namespace, as it is done in other files (i.e.
nativeparser.cpp). ;)
domore: I agree, docs might be displayed in scintilla's call tip, but first CC must handle documentation comments properly.
edit: It's possible but this require intervention into scintillaWX, IMO it is worth it. Currently call tip and auto complete hides each other.
About documentation, I tried to detect when user changes selection in autocomplete but currently I can't do that.
developers, have you any plans, ideas about documentation support?
QuoteWould be nice if the box was horizontally scrollable but that probably requires changes to scintilla.Quote
I don't know to to add scroll, but I found that box's maximum dimensions are hardcoded in wxscintilla/src/PlatWX.cpp in ListBoxImpl::GetDesiredRect()
Quote from: p2rkw on November 28, 2012, 02:51:14 AM
About documentation, I tried to detect when user changes selection in autocomplete but currently I can't do that.
developers, have you any plans, ideas about documentation support?
First, you need to use a method to recognize comments? We can get comments from the Parserthread class (not implemented), or we can find/search comments around the symbol through Scintilla's API.
Second, to show the comments, I once see that Codelite IDE use an customized window. (not the build-in one in scintilla)
Quote from: p2rkw on November 28, 2012, 02:51:14 AM
ideas about documentation support?
Well did you try the Doxyblocks plugin in the first place? You have everything you need in place there. Including scanning for docs.
I tried doxyblocks, but it seems that it only doubles functionality of doxywizard. My question was about display documentation in codeblocks.
to see doc, i.e. description of function parameters I have to minimize c::b and switch to browser, open documentation, search for function, remember parameters meaning and switch back to c::b. My intention was to display documentation in floating window above autocompletion. Something similar to http://netbeans.org/images_www/v7/1/screenshots/editor.png , for example:
(http://i.imgur.com/yrhOw.png)
And I agree that doxygen is the best tool to generate documentation, and IMO codeblocks should use its to generate docs.
Codeblocks already have (mostly unused) html viewer, maybe it can be used to display documentation? It is possible to make popup floating window with this viewer inside? It can be nice replacement for scintilla's call tip.
I think you could just use a wxPopupWindow. The info windows are popup windows.
I'd be rather careful with the popup window usage... we have very messy fights between the cc and the debugger popups.
Probably you'll have to see what is used to implement the current popup and probably add something to it.
Like a text control at the top/bottom with the comment.
An alternative idea to a popup would be to have a "CC Documentation" tab in the logs at the bottom. CC could update it whenever it felt necessary: docs on the symbol under the caret, docs on the current function, and, of course, docs on the current selection during auto-completion. This idea should not interfere with other popups, but it also may not be as intuitive.
Quote from: p2rkw on November 28, 2012, 02:51:14 AM
About documentation, I tried to detect when user changes selection in autocomplete but currently I can't do that.
Have you tried the work around of listening for key presses
WXK_UP and
WXK_DOWN, then requesting the current selection?
Alpha: yes I did. I added something like this:
Connect(wxEVT_KEY_DOWN, wxKeyEventHandler(CodeCompletion::OnKeyDown));
to Codecompletion's ctor, but my event handler wasn't called.
Quote from: Alpha on November 29, 2012, 12:29:36 AM
An alternative idea to a popup would be to have a "CC Documentation" tab in the logs at the bottom. CC could update it whenever it felt necessary: docs on the symbol under the caret, docs on the current function, and, of course, docs on the current selection during auto-completion. This idea should not interfere with other popups, but it also may not be as intuitive.
I like this idea.
Quote from: p2rkw on November 29, 2012, 01:09:53 AM
Connect(wxEVT_KEY_DOWN, wxKeyEventHandler(CodeCompletion::OnKeyDown));
Key events are not generated inside a plugin, so it is necessary to
Connect() to the editor with something like:
cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (ed)
ed->GetControl()->Connect(wxEVT_KEY_DOWN, (wxObjectEventFunction)&CodeCompletion::OnKeyDown, NULL, this);
...
void CodeCompletion::OnKeyDown(wxKeyEvent& event)
{
}
Also, take a look at:
void CodeCompletion::EditorEventHook(cbEditor* editor, wxScintillaEvent& event)
Quote from: dmoore on November 28, 2012, 11:00:57 PM
I think you could just use a wxPopupWindow.
Note that this is not available on the Mac. Maybe a HTML/RTF like control is indeed better.
We use mini frame or some such on Mac using an ifdef. The scintilla popup does the same thing.
Re html window... I would prefer the way it is done in netbeans. To have a html control means another persistent window on screen taking up space?? An alternative to two popups is to hack the tip window to add extra widgets to it.
Quote from: dmoore on November 29, 2012, 01:46:10 PM
An alternative to two popups is to hack the tip window to add extra widgets to it.
wxTipWindow is unhackable... you'll have to use wxPopupWindow or wxPopupTransinientWindow.
Sorry meant auto complete window not tip window. And why wouldn't it be hackable? Just put a sizer and extra widgets in it. But we don't have to use scintillas implementation of auto complete at all.
Quote from: dmoore on November 29, 2012, 01:46:10 PM
To have a html control means another persistent window on screen taking up space??
Clearly, it should be one window only. I didn't mean to add another.
BTW: My experience with wxMiniFrame is (however) rather bad, as it steals focus.
Correction... wxSctintilla uses either wxPopupWindow or wxFrame to display the autocomplete list control (see line 917 of PlatWX.cpp). There is an #ifdef about COCOA in the wxPopupWindow derived version, so are you sure this isn't supported on Mac in newer versions of wxWidgets?
wxCocoa is available only in wx2.9+, for wx2.8 there is only wxCarbon.
Regardless, the point stands that there is a working implementation in wxScintilla using either PopupWindow or Frame that can be adapted.
p2rkw:
First impressions - it look really bad, when longer functions are completed. It adds '...' at the end.
Is it possible to try to resize the completion window?
My first idea was to call:
ed->GetControl()->AutoCompSetMaxWidth(0);
ed->GetControl()->AutoCompSetMaxHeight(12);
before AutoComp show, but this doesn't work. Maximum size of autocomp listbox is hardcoded in ListBoxImpl::GetDesiredRect() in file PlatWX.cpp:
(...) if (maxw > 350)
maxw = 350;
add similar for maxh.
This limitations are unnecessary because later scintilla clamp rect returned by this function to values setted by AutoCompSetMaxWidth and AutoCompSetMaxHeight. So I removed this limitations and AutoCompSetMaxWidth and AutoCompSetMaxHeight works as it should be.
I removed few bugs, now default arguments, and overloads are handled correctly. If you use autocomp outside function's block argument's types will be not removed (because outside blocks are only function's definitions/declarations).
I also apped patch for PlatWX.cpp - if you apply it your autocomplete listbox will be adjusted to widest match.
I think I finished this functionality, now I will work on documentation helper.
edit: patches are now in patch tracker.
Quote from: p2rkw on November 30, 2012, 03:00:49 PM
patches are now in patch tracker.
Good work.
Both Enlargment of autocomplete's listbox (https://developer.berlios.de/patch/?func=detailpatch&patch_id=3382&group_id=5358) and CC,autocomplete: added argument's names and types to list (https://developer.berlios.de/patch/?func=detailpatch&patch_id=3381&group_id=5358).
The first one was patch on PlatWX.cpp.
Quote from: ollydbg on November 30, 2012, 03:43:11 PM
Quote from: p2rkw on November 30, 2012, 03:00:49 PM
patches are now in patch tracker.
Good work.
Both Enlargment of autocomplete's listbox (https://developer.berlios.de/patch/?func=detailpatch&patch_id=3382&group_id=5358) and CC,autocomplete: added argument's names and types to list (https://developer.berlios.de/patch/?func=detailpatch&patch_id=3381&group_id=5358).
The first one was patch on PlatWX.cpp.
Warning: These conflict with:
http://forums.next.codeblocks.org/index.php/topic,17172.msg117678.html#new
...which is a nice one, too.
Then we choose one to be committed and the second will be fixed after the commit.
Commit this one first (it was here longer :)); I will update my patch after that.
I've found some problems with this patch:
1. completing push_back of a std::vector results in vec.push_back(__x)|, but what I want to have after the completion is vec.push_back|
2. completing end of a std::vector results in vec.end()|, I want it to be vec.end|
'|' is where the cursor is after the completion.
You probably have disabled option "add parentheses after function autocomplete". Thanks for info. I'll fix it when Alpha's patch will be in svn.
btw: can you enable this option and say what you think about new behaviour?
Yes, it is disabled, but the first case will be an error even if it is enabled.
Ok, I fixed it, but now I don't have time to generate patch.
When this option is enabled and you complete push_back then argument names (in this case "__x") will be selected. It's a feature :)
What do you mean by selected?
Keep in mind that this is bug in my opinion and it can be very annoying!
Patch updated.
Btw. if I will prepare patch, should I start topic to describe it, send it directly to patch tracker, or maybe I shouldn't send anything at all?
Quote from: p2rkw on December 03, 2012, 03:30:15 PM
Btw. if I will prepare patch, should I start topic to describe it, send it directly to patch tracker, or maybe I shouldn't send anything at all?
What patch? Some other patch? Are you asking what is the accepted procedure for providing patches?
Yea, exactly.
Generally it is better to post it on the tracker and if you feel that it needs to be discussed you can start a topic in the forum...
I'm still working on doc helper, and I don't know how to check which position in autocomp list is selected. I arleady capture up and down arrows, but I can't capture mouse clicks. I got 2 ideas how to solve it:
1. create new event type i.e wxEVT_SCI_AUTOCOMP_MOVED in wxscintilla.cpp, there are already few events between C::B begin and C::B end
2. create timer in CodeCompletion that when autocompete list will be active will check which item is selected.
What should I do? Maybe you have other ideas?
Quote from: p2rkw on December 05, 2012, 01:27:32 AM
1. create new event type i.e wxEVT_SCI_AUTOCOMP_MOVED in wxscintilla.cpp, there are already few events between C::B begin and C::B end
I see in sdk\wxscintilla\src\wxscintilla.cpp
BEGIN_EVENT_TABLE(wxScintilla, wxControl)
EVT_PAINT (wxScintilla::OnPaint)
EVT_SCROLLWIN (wxScintilla::OnScrollWin)
EVT_SCROLL (wxScintilla::OnScroll)
EVT_SIZE (wxScintilla::OnSize)
EVT_LEFT_DOWN (wxScintilla::OnMouseLeftDown)
// Let Scintilla see the double click as a second click
EVT_LEFT_DCLICK (wxScintilla::OnMouseLeftDown)
EVT_MOTION (wxScintilla::OnMouseMove)
EVT_LEFT_UP (wxScintilla::OnMouseLeftUp)
#if defined(__WXGTK__) || defined(__WXMAC__)
EVT_RIGHT_UP (wxScintilla::OnMouseRightUp)
#else
EVT_CONTEXT_MENU (wxScintilla::OnContextMenu)
#endif
EVT_MOUSEWHEEL (wxScintilla::OnMouseWheel)
EVT_MIDDLE_UP (wxScintilla::OnMouseMiddleUp)
EVT_CHAR (wxScintilla::OnChar)
EVT_KEY_DOWN (wxScintilla::OnKeyDown)
EVT_KILL_FOCUS (wxScintilla::OnLoseFocus)
EVT_SET_FOCUS (wxScintilla::OnGainFocus)
EVT_SYS_COLOUR_CHANGED (wxScintilla::OnSysColourChanged)
EVT_ERASE_BACKGROUND (wxScintilla::OnEraseBackground)
EVT_MENU_RANGE (10, 16, wxScintilla::OnMenu)
EVT_LISTBOX_DCLICK (wxID_ANY, wxScintilla::OnListBox)
END_EVENT_TABLE()
So, it looks like you can add one for EVT_LISTBOX, see http://docs.wxwidgets.org/trunk/classwx_list_box.html
Quote
EVT_LISTBOX(id, func):
Process a wxEVT_COMMAND_LISTBOX_SELECTED event, when an item on the list is selected or the selection changes.
EVT_LISTBOX_DCLICK(id, func):
Process a wxEVT_COMMAND_LISTBOX_DOUBLECLICKED event, when the listbox is double-clicked.
wxScintilla::OnListBox basically just enter the selected text in autocompletion:
void wxScintilla::OnListBox(wxCommandEvent& WXUNUSED(evt))
{
m_swx->DoOnListBox();
}
void ScintillaWX::DoOnListBox() {
AutoCompleteCompleted();
}So, double click on the list box will finally call AutoCompleteCompleted(), which just enter a selected item's text.
Ollydbg, thanks a lot for advice :) Inspired by your post I tried to handle EVT_LISTBOX event:
cbStyledTextCtrl* control = editor->GetControl();
control->Connect(wxID_ANY, EVT_LISTBOX,
(wxObjectEventFunction)&CodeCompletion::OnAutocompleteListbox,
NULL, this );
but event has never occurred. So I set breakpoint on wxScintilla::OnListBox, and find out that this method is never called! So I had to go deeper and I find that wxxcintilla doesn't use wxListBox but wxListView (http://docs.wxwidgets.org/trunk/classwx_list_view.html), so I have to handle wxEVT_COMMAND_LIST_ITEM_SELECTED.
Now, all I need is documentation, but CC parser doesn't recognize them. Maybe parser should read xml generated by doxygen?
parsing comments in CC:
pros:
- builtin
- realtime parsing
cons:
- not implemented
reading from xml:
pros:
- xml is easy to read
- can read external documentation( user will only specify patches to it)
cons:
- user must have already generated docs
What you think, what will be better?
QuoteSo I had to go deeper and I find that wxxcintilla doesn't use wxListBox but wxListView, so I have to handle wxEVT_COMMAND_LIST_ITEM_SELECTED.
Good, well done!
Quote from: p2rkw on December 05, 2012, 07:17:25 PM
Now, all I need is documentation, but CC parser doesn't recognize them. Maybe parser should read xml generated by doxygen?
parsing comments in CC:
pros:
- builtin
- realtime parsing
cons:
- not implemented
reading from xml:
pros:
- xml is easy to read
- can read external documentation( user will only specify patches to it)
cons:
- user must have already generated docs
What you think, what will be better?
I prefer enhance the CodeCompletion plugin. Currently, all the c/c++ style comments were skipped in the Tokenizer. What I think is: add some kind of comment parser which is
independent from the normal c/c++ parser. Use the comment parser to find the comments "around" the Token. Because we have the file/line information in each Token, when we try to show the documents of a specific Token, we can let the comment parser to parse the code snippet around the Token position, and show the comments.
As a conclusion, the comment parser only runs when it needed. :)
Quote
Currently, all the c/c++ style comments were skipped in the Tokenizer. What I think is: add some kind of comment parser which is independent from the normal c/c++ parser. Use the comment parser to find the comments "around" the Token. Because we have the file/line information in each Token, when we try to show the documents of a specific Token, we can let the comment parser to parse the code snippet around the Token position, and show the comments.
As a conclusion, the comment parser only runs when it needed. Smiley
I don't know how to write parser from scratch. This might be lot of work. And lot of file readings may kill performance.
So, I'm going add new token types for /**, /*!, ///, //!, //!<, and store raw documentation comment in Token's object.
I hope that I can modify existing parser a bit? :)
edit: This can be done even without adding new tokens (strings in ParserConsts namespace). I can detect doc comment inside Tokenizer::SkipComments, cache it, and assign to new token in ParserThread::DoAddToken. Is this acceptable hack?
How actually it's looks like:
http://i.imgur.com/tNVsm.png
http://i.imgur.com/mfIrg.png
I used EmbendedHtmlPanel from defaultmimehandler plugin. How can I use this class without including it's source file?
Slightly unrelated, but I thought I would mention that if one can get the Scintilla lexers to run invisibly (for files not currently open), a relatively simple language independent comment parser can be created with cbStyledTextCtrl::IsComment().
@p2rkw
I think store comments in Token class will make the Token object bigger. so it(tokentree) will eat more memory. I think Alpha' idea is good.
Quote from: ollydbg on December 09, 2012, 07:47:01 AM
@p2rkw
I think store comments in Token class will make the Token object bigger. so it(tokentree) will eat more memory. I think Alpha' idea is good.
But i would think using the CC parser is necessary to figure out which comments are doc strings and what CC object they correspond to? Maybe don't need the doc strings in memory, just line/file reference.
It's not finished, but maybe one of you want to test it, and share your opinions? I hope I included all modified files in patch. It's probably conflicts with this one (http://developer.berlios.de/patch/?func=detailpatch&patch_id=3381&group_id=5358).
ollydbg: You worry about Token class' size? Documentation can be stored in separate hashmap (or map) that connects token's id to text (map can be also created for other rare data, like m_TemplateAlias). What do you think?
If you worry, about amount memory used by c::b: It may be even cheaper to store only documentation in memory, instead of loading few source files only to display short comment. Keep in mind that in current implementation, documentation is shown when user selects another item from autocomplete list. It will be also possible to read documents from external source (like xml generated by doxygen).
User should be able to disable documentation helper.
Should documentation tip shows up when user hover some symbol? Or maybe when he do ctrl + click (similarly to debugger)?
Quote from: p2rkw on December 10, 2012, 04:09:33 AM
ollydbg: You worry about Token class' size? Documentation can be stored in separate hashmap (or map) that connects token's id to text (map can be also created for other rare data, like m_TemplateAlias). What do you think?
If you look at the declaration of Token class, you will see it is already a fat body. It has many members(many wxString, many stl containers), that's why you see Codeblocks.exe occupy a lot of memory. We do not directly use "reference" in this class I think.
Quote
If you worry, about amount memory used by c::b: It may be even cheaper to store only documentation in memory, instead of loading few source files only to display short comment.
I'm not quite understand your idea. If you want to store "only documents", do you mean, you want to add another wxString member named m_Comments in Token class?
I don't mean loading few source "files", I mean when you show one Token, you only need to open one file which have this Token.
Quote
Keep in mind that in current implementation, documentation is shown when user selects another item from autocomplete list. It will be also possible to read documents from external source (like xml generated by doxygen).
User should be able to disable documentation helper.
Should documentation tip shows up when user hover some symbol? Or maybe when he do ctrl + click (similarly to debugger)?
I do not have looked into your patch, but I think showing the comments in the log panel is a good idea. Think you have a very long comments, if you show them around your mouse pointer, the tip/autocompletion window will be quite huge. :)
Quote from: ollydbg on December 10, 2012, 04:06:07 PM
I do not have looked into your patch, but I think showing the comments in the log panel is a good idea. Think you have a very long comments, if you show them around your mouse pointer, the tip/autocompletion window will be quite huge. :)
Seems to work fine as a popup window in Netbeans: http://netbeans.org/images_www/v7/1/screenshots/editor.png
(Would just need to be made scrollable for long comments)
This netbeans screenshot is mighty ugly...
another netbeans: http://www.javaworld.com/javaworld/jw-05-2009/images/net_beans_code_complete.jpg
pydev (eclipse): http://pydev.org/images/screenshot/screenshot_code_completion_self.png
The second one is a bit better...
I finished the main functionality
(http://i.imgur.com/S1iQt.png)
Well done!
What does this do to performance? (Memory/CPU)
Will this provide docs for wxWidgets?
Is this in the patch tracker?
Also have you fixed the autocomplete patch to work with current head?
I'm currently testing it and I see no problems with the second version, but the old version had a strange crash, so I want to test a bit more.
Quote from: oBFusCATed on December 15, 2012, 12:53:37 AM
I'm currently testing [...]
Reminds me that I also saw very strange behaviour like the HTML docs were shown for a (wx) class I had used last in case I added an
#include statement. This made no sense... but maybe its fixed already.
Update. Patch against revision 8706. Still not finished but works nicely :)
Actually doxygen parser recognize only few keywords: params, breief, short, result, return, see, sa.
I have no idea how to efficiently handle structural keywords: class, var, fn, etc.. I also don't know what to do with overloaded/overwritten functions: their names should be displayed on autocomplete list several times or just once? Maybe if documentation should be "inherited" from base class (and its members) when it's not present?
Quote from: p2rkw on December 24, 2012, 01:14:31 AM
Update. Patch against revision 8706. Still not finished but works nicely :)
Actually doxygen parser recognize only few keywords: params, breief, short, result, return, see, sa.
I have no idea how to efficiently handle structural keywords: class, var, fn, etc.. I also don't know what to do with overloaded/overwritten functions: their names should be displayed on autocomplete list several times or just once? Maybe if documentation should be "inherited" from base class (and its members) when it's not present?
Great work.
I just download and apply your patches. I see some building warnings:
Quote
[ 63.2%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DBUILDING_PLUGIN -iquote.objs\include -I.objs\include -I. -IE:\code\cb\wx\wxWidgets-2.8.12\include -IE:\code\cb\wx\wxWidgets-2.8.12\contrib\include -IE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\mozilla_chardet -c plugins\codecompletion\codecompletion.cpp -o .objs\plugins\codecompletion\codecompletion.o
plugins\codecompletion\codecompletion.cpp: In member function 'int CodeCompletionHelper::Doxygen::DoxygenParser::FindNextKeyword(const wxString&)':
plugins\codecompletion\codecompletion.cpp:508:34: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
plugins\codecompletion\codecompletion.cpp: In member function 'int CodeCompletionHelper::Doxygen::DoxygenParser::CheckKeyword(const wxString&)':
plugins\codecompletion\codecompletion.cpp:555:36: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
plugins\codecompletion\codecompletion.cpp:559:63: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
plugins\codecompletion\codecompletion.cpp:596:50: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
plugins\codecompletion\codecompletion.cpp:609:41: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
plugins\codecompletion\codecompletion.cpp: In member function 'int CodeCompletionHelper::Doxygen::DoxygenParser::GetParagraphArgument(const wxString&, wxString&)':
plugins\codecompletion\codecompletion.cpp:626:36: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
plugins\codecompletion\codecompletion.cpp: In member function 'void CodeCompletionHelper::Doxygen::DoxygenParser::GetWordArgument(const wxString&, wxString&)':
plugins\codecompletion\codecompletion.cpp:642:36: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
plugins\codecompletion\codecompletion.cpp: In member function 'int CodeCompletionHelper::Doxygen::DoxygenParser::GetLineArgument(const wxString&, wxString&)':
plugins\codecompletion\codecompletion.cpp:666:36: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
plugins\codecompletion\codecompletion.cpp: In member function 'bool CodeCompletionHelper::Doxygen::DoxygenParser::IsEnd(const wxString&) const':
plugins\codecompletion\codecompletion.cpp:736:38: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
plugins\codecompletion\codecompletion.cpp: In member function 'void CodeCompletion::EditorEventHook(cbEditor*, wxScintillaEvent&)':
plugins\codecompletion\codecompletion.cpp:2774:34: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x [enabled by default]
plugins\codecompletion\codecompletion.cpp: In member function 'Token* CodeCompletion::GetAutocompToken(int)':
plugins\codecompletion\codecompletion.cpp:4776:68: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
plugins\codecompletion\codecompletion.cpp: At global scope:
plugins\codecompletion\codecompletion.cpp:331:16: warning: 'int CodeCompletionHelper::AutocompRemoveArgsTypes(wxString&)' defined but not used [-Wunused-function]
Some comment from a very quick view on the patch files:
1, I see some tabs, here, I think they should be converted to white-spaces.
2, I see a lot of code in codecompletion.cpp, I personally think the codecompletion.cpp is too large, is it possible to add a new file (e.g. DoxygenParser.cpp)
Quote from: ollydbg on December 24, 2012, 07:51:31 AM
2, [...] is it possible to add a new file (e.g. DoxygenParser.cpp)
I second that.
Can you make the comment panel's background color different from the code editor's background?
currently, they are both white.
See the screen shot below:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-12-24151815_zpsa402b0c8.png)
EDIT: it seems that click on the HTML link(in the comment panel) does not work.
Quote from: ollydbg on December 24, 2012, 08:19:55 AM
Can you make the comment panel's background color different from the code editor's background?
Why not just simply provide a border?
QuoteWhat does this do to performance? (Memory/CPU)
Plain documentation is stored in additional map, so memory isn't wasted when token haven't got documentation.
Html is generated on the fly from tokens generated (and cached) in CodeCompletion::CodeComplete, there aren't additional searches in token tree. Most of the times token index is passed in link's href, so it can be obtained from tree without search.
QuoteI second that.
And me too :) But first I have to find out how create patch that adds files to repo.
QuoteCan you make the comment panel's background color different from the code editor's background?
currently, they are both white.
I forgot that default background color is white :) I already added border. I think that colors of background, text and links should be customizable.
QuoteEDIT: it seems that click on the HTML link(in the comment panel) does not work.
Which exactly doesn't work? Can you try this code:
struct ThisLinkWorks{};
//! A test class.
/*!
A more elaborate class description.
*/
class Test
{
public:
//! An enum.
/*! More detailed enum description. */
enum TEnum {
TVal1 = 2, /*!< Enum value TVal1. */
TVal2, /*!< Enum value TVal2. */
TVal3 /*!< Enum value TVal3. */
}
//! Enum pointer.
/*! Details. */
*enumPtr,
//! Enum variable.
/*! Details. */
enumVar;
//! A constructor.
//! Constructing constructor of constructive Test class.
/*!
A more elaborate description of the constructor.
*/
Test();
//! A destructor.
/*!
A more elaborate description of the destructor.
*/
~Test();
//! A normal member taking two arguments and returning an <font color=red>integer</font> value.
/*!
\param a an integer argument.
\param s a constant character pointer.
\return The test results
\sa Test, ~Test, Test() testMeToo publicVar
*/
int testMe(int a, const char* s);
//! A pure virtual member.
/*!
\sa testMe()
\param c1 the first argument.
\param c2 the second argument.
*/
virtual void testMeToo(char c1, char c2) = 0;
//! A public variable.
/*!
Details.
*/
int publicVar;
//! A function variable.
/*!
Details.
*/
int (*handler)(int a, int b);
ThisLinkWorks function4(ThisLinkDoesntWork tldw);
};PS. Can also try to implement methods using codecompletion?
Quote from: p2rkw on December 26, 2012, 04:31:42 PM
Which exactly doesn't work? Can you try this code:
Well in fact, on Windows none of the blue links works for me:
- Open Decl/Impl,
- Close
- Top
...what would be the expected result? I thought its maybe not yet implemented.
Quote from: p2rkw on December 26, 2012, 04:31:42 PM
QuoteI second that.
And me too :) But first I have to find out how create patch that adds files to repo.
If you use TortoiseSVN under Windows, just right click on the new file, and select "add" command. If you use SVN command, I believe there is a similar "add" command.
After that, the new file's content will be included in your patch.
Quote
PS. Can also try to implement methods using codecompletion?
I don't understand this sentence. ???
Quote from: ollydbg on December 24, 2012, 07:51:31 AM
2, [...] is it possible to add a new file (e.g. DoxygenParser.cpp)
Please stick to lower case file names.
QuotePlease stick to lower case file names.
Ok.
QuoteWell in fact, on Windows none of the blue links works for me:
I just tested it on windows, and it works very bad, much worse than on linux. Fortunately I know how to fix it.
QuoteI don't understand this sentence.
Sorry, if it wasn't clear. I mean when you have function/method declaration:
void function(int arg0, float arg1); you can use autocomplete to write implementation easily:
void fun| // <- use autocomplete here and you will get
void function(int arg0, float arg1)The only requirement is that implementation must be outside block.
Quote from: p2rkw on December 28, 2012, 07:02:38 PM
void fun| // <- use autocomplete here and you will get void function(int arg0, float arg1)The only requirement is that implementation must be outside block.
Juts my 2 cents on that one: This should definitely be an option, off by default. Otherwise we will get tons of reports how to turn it off.
As a general rule: Every automatism that affects the way you write code or something that even changes written code must be an option unless you need a special key combination to activate it.
I fixed windows related issues, but still it isn't configurable. I can generate and upload patch if you want to test it.
Next update, now all newly added functionalities are disabled by default. To enable them you have modify your config file manually.
<USE_DOCUMENTATION_HELPER bool="1" />
<DOCUMENTATION_HELPER_BACKGROUND_COLOR>
<colour r="255" g="255" b="255" />
</DOCUMENTATION_HELPER_BACKGROUND_COLOR>
<DOCUMENTATION_HELPER_TEXT_COLOR>
<colour r="0" g="0" b="0" />
</DOCUMENTATION_HELPER_TEXT_COLOR>
<DOCUMENTATION_HELPER_LINK_COLOR>
<colour r="0" g="0" b="255" />
</DOCUMENTATION_HELPER_LINK_COLOR>
These lines enables documentation helper, and sets colours used in generated html document.
<DETECT_IMPLEMENTATION bool="1" />
This one enables functionality described in my previous post - if you use autocomplete in global scope or inside class declaration then arguments' types and names will be added.
<SORT_CRITERION1 int="2" />
<SORT_CRITERION2 int="1" />
<SORT_CRITERION3 int="6" />
<SORT_CRITERION4 int="5" />
<SORT_CRITERION5 int="7" />
<SORT_CRITERION6 int="8" />
<SORT_CRITERION7 int="4" />
<SORT_CRITERION8 int="0" />
By the way I also added possibility to sort autocomplete list. You can use up to 8 sort criteria. Lower criterion number means higher priority (SORT_CRITERION1 has highest priority). Argument's specify how auto complete list will be sorted. Possible values and its meanings:
enum Criterium
{
NO_CRITERION = 0,
CMP_SCOPE = 1, // compare by token's scope
IS_LOCAL = 2, // compare by Token::m_IsTemp: checks if token is local variable
CMP_NAME = 3, //compare by token's name
CMP_KIND = 4, //compare by token's kind with order defined by Token::m_TokenKind value; don't use this comparator with lower priority than IS_FN, IS_VAR, IS_CLASS, IS_NS
IS_FN = 5, // compare by token's kind: checks if token is function
IS_VAR = 6, //compare by token's kind: checks if token is variable
IS_CLASS = 7, // ... is it class
IS_NS = 8, // ... is it namespace
};
And if you set criterion to "0" (NO_CRITERION) all criteria with lower priority will be disabled, so to sort only by token's name simply set SORT_CRITERION1 to "0".
edit: those tags should be sub-nodes of <code_completion> node.
edit2: Changes in project files are not included in patch, so remember to add doxygen_parser.* files to project.
Quote from: p2rkw on January 07, 2013, 12:24:14 AM
<SORT_CRITERION1 int="2" />
<SORT_CRITERION2 int="1" />
<SORT_CRITERION3 int="6" />
<SORT_CRITERION4 int="5" />
<SORT_CRITERION5 int="7" />
<SORT_CRITERION6 int="8" />
<SORT_CRITERION7 int="4" />
<SORT_CRITERION8 int="0" />
By the way I also added possibility to sort autocomplete list. You can use up to 8 sort criteria. Lower criterion number means higher priority (SORT_CRITERION1 has highest priority). Argument's specify how auto complete list will be sorted. Possible values and its meanings:
enum Criterium
{
NO_CRITERION = 0,
CMP_SCOPE = 1, // compare by token's scope
IS_LOCAL = 2, // compare by Token::m_IsTemp: checks if token is local variable
CMP_NAME = 3, //compare by token's name
CMP_KIND = 4, //compare by token's kind with order defined by Token::m_TokenKind value; don't use this comparator with lower priority than IS_FN, IS_VAR, IS_CLASS, IS_NS
IS_FN = 5, // compare by token's kind: checks if token is function
IS_VAR = 6, //compare by token's kind: checks if token is variable
IS_CLASS = 7, // ... is it class
IS_NS = 8, // ... is it namespace
};
And if you set criterion to "0" (NO_CRITERION) all criteria with lower priority will be disabled, so to sort only by token's name simply set SORT_CRITERION1 to "0".
edit: those tags should be sub-nodes of <code_completion> node.
edit2: Changes in project files are not included in patch, so remember to add doxygen_parser.* files to project.
If this is some separate functionallity it will be best to post a separate patch...
Also, I guess you'll have to provide some gui...
I know that, but I don't know will I have time in this week.
Quote from: p2rkw on January 07, 2013, 12:24:14 AM
Next update, now all newly added functionalities are disabled by default. To enable them you have modify your config file manually.
Unfortunately it doesn't compile. The error I get is:
C:\Devel\CodeBlocks\src\plugins\codecompletion\parser\parserthread.cpp: In constructor 'ParserThread::ParserThread(ParserBase*, const wxString&, bool, ParserThreadOptions&, TokenTree*)':
C:\Devel\CodeBlocks\src\plugins\codecompletion\parser\parserthread.cpp:200:72: error: no matching function for call to 'Tokenizer::SetTokenizerOption(bool&)'You changed the interface of that method from:
void SetTokenizerOption(bool wantPreprocessor)...to:
void SetTokenizerOption(bool wantPreprocessor, bool storeDocumentation)...maybe you forgot to update all its calls / references?
Oh, sorry. I cut out too much when I was removing unnecessary chunks from patch.
You can use revised patch (in attachment) or apply this:
Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (wersja 8771)
+++ src/plugins/codecompletion/parser/parserthread.cpp (kopia robocza)
@@ -197,7 +197,8 @@
m_IsBuffer(parserThreadOptions.useBuffer),
m_Buffer(bufferOrFilename)
{
- m_Tokenizer.SetTokenizerOption(parserThreadOptions.wantPreprocessor);
+ bool storeDocumentation = true;
+ m_Tokenizer.SetTokenizerOption(parserThreadOptions.wantPreprocessor, storeDocumentation);
if (!m_TokenTree)
cbThrow(_T("m_TokenTree is a nullptr?!"));
}
Quote from: p2rkw on January 07, 2013, 06:33:07 PM
You can use revised patch (in attachment) or apply this:
Yes, work now... I have it applied and report if something is badly broken... ;-)
I have a wired build issue:
Quote[ 58.3%] g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DBUILDING_PLUGIN -iquote.objs\include -I.objs\include -I. -IE:\code\cb\wx\wxWidgets-2.8.12\include -IE:\code\cb\wx\wxWidgets-2.8.12\contrib\include -IE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -c plugins\codecompletion\codecompletion.cpp -o .objs\plugins\codecompletion\codecompletion.o
In file included from plugins\codecompletion\codecompletion.h:17:0,
from plugins\codecompletion\codecompletion.cpp:53:
plugins\codecompletion\doxygen_parser.h:181:9: error: expected identifier before numeric constant
plugins\codecompletion\doxygen_parser.h:181:9: error: expected '}' before numeric constant
plugins\codecompletion\doxygen_parser.h:181:9: error: expected unqualified-id before numeric constant
plugins\codecompletion\doxygen_parser.h:197:37: error: 'Command' was not declared in this scope
plugins\codecompletion\doxygen_parser.h:197:50: error: expected primary-expression before 'const'
plugins\codecompletion\doxygen_parser.h:197:72: error: expected primary-expression before 'const'
plugins\codecompletion\doxygen_parser.h:199:40: error: 'Command' was not declared in this scope
plugins\codecompletion\doxygen_parser.h:199:53: error: expected primary-expression before 'const'
plugins\codecompletion\doxygen_parser.h:199:75: error: expected primary-expression before 'int'
plugins\codecompletion\doxygen_parser.h:201:12: error: 'Command' does not name a type
plugins\codecompletion\doxygen_parser.h:207:27: error: uninitialized const 'separatorTag' [-fpermissive]
plugins\codecompletion\doxygen_parser.h:211:39: error: expected ')' before '*' token
plugins\codecompletion\doxygen_parser.h:213:27: error: expected constructor, destructor, or type conversion before ';' token
plugins\codecompletion\doxygen_parser.h:229:23: error: non-member function 'bool IsAttached()' cannot have cv-qualifier
plugins\codecompletion\doxygen_parser.h:235:1: error: expected unqualified-id before 'protected'
plugins\codecompletion\doxygen_parser.h:251:1: error: expected unqualified-id before 'public'
plugins\codecompletion\doxygen_parser.h:259:1: error: expected unqualified-id before 'protected'
plugins\codecompletion\doxygen_parser.h:284:5: error: expected unqualified-id before 'private'
plugins\codecompletion\doxygen_parser.h:284:5: error: expected unqualified-id before 'protected'
plugins\codecompletion\doxygen_parser.h:284:5: error: 'virtual' outside class declaration
plugins\codecompletion\doxygen_parser.h:284:5: error: non-member function 'const wxEventTable* GetEventTable()' cannot have cv-qualifier
plugins\codecompletion\doxygen_parser.h:284:5: error: no matching function for call to 'wxEventHashTable::wxEventHashTable()'
plugins\codecompletion\doxygen_parser.h:284:5: note: candidates are:
E:\code\cb\wx\wxWidgets-2.8.12\include/wx/event.h:2380:5: note: wxEventHashTable::wxEventHashTable(const wxEventHashTable&)
E:\code\cb\wx\wxWidgets-2.8.12\include/wx/event.h:2380:5: note: candidate expects 1 argument, 0 provided
E:\code\cb\wx\wxWidgets-2.8.12\include/wx/event.h:2342:5: note: wxEventHashTable::wxEventHashTable(const wxEventTable&)
E:\code\cb\wx\wxWidgets-2.8.12\include/wx/event.h:2342:5: note: candidate expects 1 argument, 0 provided
plugins\codecompletion\doxygen_parser.h:284:5: error: 'virtual' outside class declaration
plugins\codecompletion\doxygen_parser.h:284:5: error: non-member function 'wxEventHashTable& GetEventHashTable()' cannot have cv-qualifier
plugins\codecompletion\doxygen_parser.h:285:1: error: expected declaration before '}' token
The first error happens here:
class DocumentationHelper : public /*wxHtmlWindow*/ wxEvtHandler
{
//typedef wxHtmlWindow BaseClass;
typedef wxEvtHandler BaseClass;
public:
enum Command
{
NO_COMMAND,
DISPLAY_TOKEN, //args: token index
SEARCH, //args: token name
SEARCH_ALL, //args: token name **************Here
OPEN_DECL, //args: token index
OPEN_IMPL, //args: token index
CLOSE, //args: -----
};
I just run the preprocessor:
Quote
@echo Add MinGW path
@set PATH=E:\code\gcc\PCXMinGW463\bin;%PATH%
g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -DBUILDING_PLUGIN -iquote.objs\include -I.objs\include -I. -IE:\code\cb\wx\wxWidgets-2.8.12\include -IE:\code\cb\wx\wxWidgets-2.8.12\contrib\include -IE:\code\cb\wx\wxWidgets-2.8.12\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\mozilla_chardet -Iinclude\mozilla_chardet\mfbt -Iinclude\mozilla_chardet\nsprpub\pr\include -Iinclude\mozilla_chardet\xpcom -Iinclude\mozilla_chardet\xpcom\base -Iinclude\mozilla_chardet\xpcom\glue -E plugins\codecompletion\codecompletion.cpp >> a.txt
The wired thing is, when I look at the a.txt(the preprocessed output), I see such code:
class DocumentationHelper : public wxEvtHandler
{
typedef wxEvtHandler BaseClass;
public:
enum Command
{
NO_COMMAND,
DISPLAY_TOKEN,
SEARCH,
0x0,
OPEN_DECL,
OPEN_IMPL,
CLOSE,
};
I don't know where the "0x0" comes???? I just searched the whole file, and I see no macro definition of "SEARCH_ALL". I have no idea what happens.....
EDIT:
It looks like I can add such code to avoid the issue.
#ifdef SEARCH_ALL
#undef SEARCH_ALL
#endif
But I still have no idea where does the previous "SEARCH_ALL" defined.
If you don't know where macro is defined, then it's defined in windows.h :) Thanks for information, I will change this name.
Ok, by putting the text:
<USE_DOCUMENTATION_HELPER bool="1" />
<DOCUMENTATION_HELPER_BACKGROUND_COLOR>
<colour r="255" g="255" b="255" />
</DOCUMENTATION_HELPER_BACKGROUND_COLOR>
<DOCUMENTATION_HELPER_TEXT_COLOR>
<colour r="0" g="0" b="0" />
</DOCUMENTATION_HELPER_TEXT_COLOR>
<DOCUMENTATION_HELPER_LINK_COLOR>
<colour r="0" g="0" b="255" />
</DOCUMENTATION_HELPER_LINK_COLOR>
in the configure file, section:
Quote
<code_completion>
....
</code_completion>
I'm happy testing this new feature, really good job, p2rkw!!!
Quote from: p2rkw on January 10, 2013, 03:10:34 PM
If you don't know where macro is defined, then it's defined in windows.h :) Thanks for information, I will change this name.
Nope, this time its well hidden in "
ntddchgr.h" of the DDK ([MinGW]\include\ddk\) of MinGW.
This shows very nice, how badly macros can suck.
Quote from: MortenMacFly on January 10, 2013, 03:22:32 PM
Quote from: p2rkw on January 10, 2013, 03:10:34 PM
If you don't know where macro is defined, then it's defined in windows.h :) Thanks for information, I will change this name.
Nope, this time its well hidden in "ntddchgr.h" of the DDK ([MinGW]\include\ddk\) of MinGW.
This shows very nice, how badly macros can suck.
Oh, and BTW: In my personal projects I always declare enums as following:
enum ECommand
{
eNO_COMMAND,
eDISPLAY_TOKEN, //args: token index
eSEARCH, //args: token name
eSEARCH_ALL, //args: token name
eOPEN_DECL, //args: token index
eOPEN_IMPL, //args: token index
eCLOSE, //args: -----
};
Notice the prefixes... this usually never conflicts with
#defines, as they are 99% of the cases declared upper-case only.
Gui added, last bugs fixed... It seems to be finished now :) http://developer.berlios.de/patch/?func=detailpatch&patch_id=3381&group_id=5358
(Ability to define custom sort order had been removed from this patch, so remember to clean your configuration file.)
Quote from: p2rkw on January 13, 2013, 10:56:10 PM
Gui added, last bugs fixed... It seems to be finished now :) http://developer.berlios.de/patch/?func=detailpatch&patch_id=3381&group_id=5358
(Ability to define custom sort order had been removed from this patch, so remember to clean your configuration file.)
Thanks! the patch is big, so I just apply the patch, and build it. I see two build warnings:
1,
plugins\codecompletion\codecompletion.cpp|1658|warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x [enabled by default]|
The code is:
ccSearchData searchData { control, editor->GetFilename() };So, it would better:
ccSearchData searchData= { control, editor->GetFilename() };2,
plugins\codecompletion\doxygen_parser.cpp|559|warning: comparison between signed and unsigned integer expressions [-Wsign-compare]|Here
for(int i = 0; i < (size_t)(sizeof(arguments)/sizeof(arguments[0])); ++i )i should be unsigned int.
:)
size_t
Ok, I'll fix it in next few days.
Quote from: p2rkw on January 16, 2013, 02:05:04 AM
Ok, I'll fix it in next few days.
I did that already besides quite some other refinements. It did neither compile with wx29 nor under 64 bit. The include chain was wrong, you defined types twice and so on... Nothing serious, but it needed to be fixed. Maybe I should post an updated patch... Just I need to sort out the stuff...
It will be nice.
Actually I added auto hide to documentation window. It's only few lines of code, but makes this window much less annoying.
Quote from: p2rkw on January 17, 2013, 01:14:09 AM
It will be nice.
Actually I added auto hide to documentation window. It's only few lines of code, but makes this window much less annoying.
Update the patch, I can integrate. I'll provide a refined one after that. Otherwise we move in circles.. ;-)
Quote from: Alpha on December 08, 2012, 12:20:00 AM
Slightly unrelated, but I thought I would mention that if one can get the Scintilla lexers to run invisibly (for files not currently open), a relatively simple language independent comment parser can be created with cbStyledTextCtrl::IsComment().
@Alpha, in plugins\codecompletion\coderefactoring.cpp, function
size_t CodeRefactoring::SearchInFiles(const wxArrayString& files, const wxString& targetText)
There is some usage of an invisible cbStyledTextCtrl, and fill it with the text, and I think later use cbStyledTextCtrl::IsXXXX() to check styles.
EDIT: I'm not look deep into p2rkw's patch, but I think using a invisible cbStyledTextCtrl is an alternative way to catch document strings on the fly.
@All:
I'm looking forward to see the updated patch against SVN HEAD :).
Also:
"return wxString();"should use wxEmptyString, right?
Quote from: ollydbg on March 01, 2013, 07:57:07 AM
Also:
"return wxString();"should use wxEmptyString, right?
Yes, I've done all such adjustments already in my local copy. I still need to merge and sort out from/with trunk as there have been many CC related changes recently. If I find the time for that I can provide a cleaned-up patch. The patch in the patch-tracker if of no use anymore. Hence it also doesn't make sense for p2rkw to work on that - I've done it already, just not to public. I am still on it - its not lost... don't worry.
@p2rkw: How difficult would it be to extend the parser to accept comments on more complicated declarations, ex. the following from stl:
/**
* @brief This does what you think it does.
* @ingroup sorting_algorithms
* @param a A thing of arbitrary type.
* @param b Another thing of arbitrary type.
* @return The lesser of the parameters.
*
* This is the simple classic generic implementation. It will work on
* temporary expressions, since they are only evaluated once, unlike a
* preprocessor macro.
*/
template<typename _Tp>
inline const _Tp&
min(const _Tp& __a, const _Tp& __b)
{
// concept requirements
__glibcxx_function_requires(_LessThanComparableConcept<_Tp>)
//return __b < __a ? __b : __a;
if (__b < __a)
return __b;
return __a;
}
Alpha: thanks for info, I'll try to fix it in next few days.
Attached patch fixes issue reported by Alpha. Multi line declarations should be handled properly now.
Edit: patch removed.
Testing (and your other patch (http://forums.next.codeblocks.org/index.php/topic,16556.msg120744.html#msg120744))...
This patch works.
Do these functions have a purpose?
F:\cb\src\plugins\codecompletion\doxygen_parser.cpp:26:12: warning: 'int GetAverangeCharWidth(cbStyledTextCtrl*, int)' defined but not used [-Wunused-function]
F:\cb\src\plugins\codecompletion\parser\tokentree.cpp:96:17: warning: 'bool TokenTreeHelper::CompareBaseArguments(const wxString&, const wxString&)' defined but not used [-Wunused-function]
If I am author of those functions then they should be removed.
In CompareBaseArguments I tried to ignore arguments names and compare it only by its types, but this function is not finished. I don't know how it gets into trunk :)
Quote from: Alpha on March 16, 2013, 01:22:54 AM
This patch works.
Never mind.
When I do not enable new features of the C++ language, the parser correctly skips items such as
cbegin(),
however, the doxygen parser does not skip them. All of the following documentation is appended to
size().
#ifdef __GXX_EXPERIMENTAL_CXX0X__
/**
* Returns a read-only (constant) iterator that points to the
* first element in the %vector. Iteration is done in ordinary
* element order.
*/
const_iterator
cbegin() const
{ return const_iterator(this->_M_impl._M_start); }
/**
* Returns a read-only (constant) iterator that points one past
* the last element in the %vector. Iteration is done in
* ordinary element order.
*/
const_iterator
cend() const
{ return const_iterator(this->_M_impl._M_finish); }
/**
* Returns a read-only (constant) reverse iterator that points
* to the last element in the %vector. Iteration is done in
* reverse element order.
*/
const_reverse_iterator
crbegin() const
{ return const_reverse_iterator(end()); }
/**
* Returns a read-only (constant) reverse iterator that points
* to one before the first element in the %vector. Iteration
* is done in reverse element order.
*/
const_reverse_iterator
crend() const
{ return const_reverse_iterator(begin()); }
#endif
// [23.2.4.2] capacity
/** Returns the number of elements in the %vector. */
size_type
size() const
{ return size_type(this->_M_impl._M_finish - this->_M_impl._M_start); }
Good catch Alpha.
Here's next patch that fixes both issues.
All seems in order; committed.
New problem code identified:
enum TokenizerState
{
tsSkipEqual = 0x0001, /// Skip the assignment statement
tsSkipQuestion = 0x0002, /// Skip the conditional evaluation statement
tsSkipSubScrip = 0x0004, /// Skip the array-subscript notation statement
tsSingleAngleBrace = 0x0008, /// Reserve angle braces
tsReadRawExpression = 0x0010, /// Reserve every chars
tsSkipNone = 0x1000, /// Skip None
// convenient masks
tsSkipUnWanted = tsSkipEqual | tsSkipQuestion | tsSkipSubScrip,
tsTemplateArgument = tsSkipUnWanted | tsSingleAngleBrace
};
All of the line comments are attached to the token after them. So, for example, tsSkipUnWanted says "Skip None" (I am not sure if this issue existed previously though).
I was looking for bug for an hour, when I found out that's not a bug. Read manual to see how those comments should be formatted: http://www.stack.nl/~dimitri/doxygen/manual/docblocks.html#memberdoc
Quote from: p2rkw on April 05, 2013, 10:24:29 PM
Read manual [...]
Ah ha! It is a feature, not a bug ;) . Thanks for pointing that out. (I guess I need to do some more manual reading...)
Quote from: Alpha on April 06, 2013, 03:13:47 AM
Quote from: p2rkw on April 05, 2013, 10:24:29 PM
Read manual [...]
Ah ha! It is a feature, not a bug ;) . Thanks for pointing that out. (I guess I need to do some more manual reading...)
Almost no users do this.
I also have to write documentation for the stuff I do at work ( :( ) and less than 10% ofthe users read it.
Quote from: jens on April 06, 2013, 09:02:46 AM
Almost no users do this.
Erm... I do it
all the time to doc member vars or enum/struct memebers in my S/W projects. ;-)
Its quite convenient for that purpose. My usual style is
//!< (fwiw).
In the example here the arrows seems missing...?!
Quote from: MortenMacFly on April 06, 2013, 12:09:07 PM
Quote from: jens on April 06, 2013, 09:02:46 AM
Almost no users do this.
Erm... I do it all the time to doc member vars or enum/struct memebers in my S/W projects. ;-)
I mean almost no users do read manuals, they all try to do stuff by trial and error and hope someone comes to clean up the mess afterwards.
Quote from: jens on April 06, 2013, 12:27:46 PM
I mean almost no users do read manuals, they all try to do stuff by trial and error and hope someone comes to clean up the mess afterwards.
Ah - that thing... a manual... a prof. at the university where I studied used to say: "Products that require a manual to be used are a design failure." :-) I kind of like that way of thinking... but well... for s/w it maybe different...
Something off-topic, I think that when something(like new feature is added to C::B), the developer should also add some text entry on the C::B manual currently in Latex format. (If you look at the GDB development, they have a very nice rule, that the docs and the code base are all synchronized)
I hope I am in the right place to re-post this, but I have reported an issue with autocompletion tooltip here http://forums.next.codeblocks.org/index.php/topic,17647.msg121548.html#msg121548 (http://forums.next.codeblocks.org/index.php/topic,17647.msg121548.html#msg121548).
Also, another issue I just noticed is that when I type for example a header file and press Return key (on Windows), it does not autocomplete header's name with a >, but it works like this on Debian wheezy.
If I press Tab key on Windows, it autocompletes the name with >, but not working on Debian wheezy.
Is this the right behavior for this mechanism? Please advice, cheers.
Definitely not the right place.
Still so much to learn...at least the issue I have reported, is it valid or not?