Patch: function arguments added to autocomplete tooltip

[oBFusCATed]

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...

[p2rkw]

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?

[ollydbg]

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

Code Select Expand



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

    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:

Code Select Expand


void wxScintilla::OnListBox(wxCommandEvent& WXUNUSED(evt))
{
    m_swx->DoOnListBox();
}


Code Select Expand


void ScintillaWX::DoOnListBox() {
    AutoCompleteCompleted();
}

So, double click on the list box will finally call AutoCompleteCompleted(), which just enter a selected item's text.

[p2rkw]

Ollydbg, thanks a lot for advice Inspired by your post I tried to handle EVT_LISTBOX event:

Code Select Expand


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, 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?

[ollydbg]

So 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!

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.

[p2rkw]

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?

[p2rkw]

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?

[Alpha]

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().

[ollydbg]

@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.

[dmoore]

@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.

[p2rkw]

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.

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)?  

[ollydbg]

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.

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.

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.

[dmoore]

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)

[oBFusCATed]

This netbeans screenshot is mighty ugly...

[dmoore]

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