Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Clang CC
ollydbg:
@yves:
I think the 20 ms lock time can be removed, at least I see a time delay in the ccmanager, see below:
--- Code: ---void CCManager::OnEditorHook(cbEditor* ed, wxScintillaEvent& event)
{
wxEventType evtType = event.GetEventType();
if (evtType == wxEVT_SCI_CHARADDED)
{
const wxChar ch = event.GetKey();
// get the char set the active ccplugin is interest to trigger the call tip
CCPluginCharMap::const_iterator ctChars = m_CallTipChars.find(GetProviderFor(ed));
if (ctChars == m_CallTipChars.end())
ctChars = m_CallTipChars.find(nullptr); // default char set
// Are there any characters which could trigger the call tip?
if (ctChars->second.find(ch) != ctChars->second.end())
{
int tooltipMode = Manager::Get()->GetConfigManager(wxT("ccmanager"))->ReadInt(wxT("/tooltip_mode"), 1);
if ( tooltipMode != 3 // keybound only
|| m_CallTipActive != wxSCI_INVALID_POSITION )
{
wxCommandEvent pendingShow(cbEVT_DEFERRED_CALLTIP_SHOW);
AddPendingEvent(pendingShow);
}
}
else
{
cbStyledTextCtrl* stc = ed->GetControl();
const int pos = stc->GetCurrentPos();
const int wordStartPos = stc->WordStartPosition(pos, true);
// get the char set the active ccplugin is interest to trigger the suggestion list
CCPluginCharMap::const_iterator alChars = m_AutoLaunchChars.find(GetProviderFor(ed));
if (alChars == m_AutoLaunchChars.end())
alChars = m_AutoLaunchChars.find(nullptr); // default char set
// auto suggest list can be triggered either:
// 1, some number of chars are entered
// 2, an interested char belong to alChars is entered
int autolaunchCt = Manager::Get()->GetConfigManager(wxT("ccmanager"))->ReadInt(wxT("/auto_launch_count"), 3);
/* TODO (ollydbg#1#02/22/16): What does the magic number 4 means? */
if ( (pos - wordStartPos >= autolaunchCt && !stc->AutoCompActive())
|| pos - wordStartPos == autolaunchCt + 4 )
{
CodeBlocksEvent evt(cbEVT_COMPLETE_CODE);
Manager::Get()->ProcessEvent(evt);
}
else if (alChars->second.find(ch) != alChars->second.end())
{
/* TODO (ollydbg#1#02/22/16): What does the 10 ms used for? Can we just ask plugin to start a code completion session? */
m_AutoLaunchTimer.Start(10, wxTIMER_ONE_SHOT);
m_AutocompPosition = pos; // remember the current caret position
}
}
}
...
--- End code ---
You can see, there are 10 ms there.
--- Quote ---On the other hand, I do think the 'GetAutocomplist'-call in the cc-plugin framework looks like an afterthought, something with a request event and a response event would probably have been much nicer, but I'm unaware of the lowlevel choices and scintilla if that would even be possible.
--- End quote ---
I think this is a good method, and we can go with this direction.
yvesdm3000:
--- Quote from: ollydbg on February 23, 2016, 08:08:58 am ---@yves:
I think the 20 ms lock time can be removed, at least I see a time delay in the ccmanager, see below:
You can see, there are 10 ms there.
--- End quote ---
This is not the same timeout. The 20 ms comes after the 10 ms you identified and gives Clang 20 ms to calculate the CC results. If it can do it in 20ms, the code-completion results are returned immediately, otherwise the clang-plugin will post a new code-completion request when the results have arrived.
--- Quote ---
--- Quote ---On the other hand, I do think the 'GetAutocomplist'-call in the cc-plugin framework looks like an afterthought, something with a request event and a response event would probably have been much nicer, but I'm unaware of the lowlevel choices and scintilla if that would even be possible.
--- End quote ---
I think this is a good method, and we can go with this direction.
--- End quote ---
Beware that with the current code-completion support in C::B, it is very complex where a code-completion is requested, handled in a thread, the editor is then modified and then when the operation is finished, the plugin needs to figure out if the code-completion still applies because another code completion might have come in, it might be identical, it might not be, the same request might be pending, and then you do another one in our own callback handler etc... The amount of cases where it can do something else than the user expects is very high.
Nevertheless it's there, in 16.01 so we'll live with it.
Yves
yvesdm3000:
Oh, and I pushed some doxygen documentation to the 'staging' branch. It's not everything, but it's a start.
Yves
ollydbg:
--- Quote from: yvesdm3000 on February 23, 2016, 08:39:08 am ---
--- Quote from: ollydbg on February 23, 2016, 08:08:58 am ---@yves:
I think the 20 ms lock time can be removed, at least I see a time delay in the ccmanager, see below:
You can see, there are 10 ms there.
--- End quote ---
This is not the same timeout. The 20 ms comes after the 10 ms you identified and gives Clang 20 ms to calculate the CC results. If it can do it in 20ms, the code-completion results are returned immediately, otherwise the clang-plugin will post a new code-completion request when the results have arrived.
--- End quote ---
You are right, the 20 ms lock is from clangcc, but 10 ms delay is from ccmanager, I mean we do not need the 10ms delay(note that under windows 10ms could be 16ms, because the system time tick), and we just start the clangcc, thus we can save a lot of time.
--- Quote from: yvesdm3000 on February 23, 2016, 08:40:20 am ---Oh, and I pushed some doxygen documentation to the 'staging' branch. It's not everything, but it's a start.
Yves
--- End quote ---
Great job!
I think I will add some doxygen style document to ccmanager class either. :)
ollydbg:
--- Quote from: yvesdm3000 on February 23, 2016, 08:39:08 am ---Beware that with the current code-completion support in C::B, it is very complex where a code-completion is requested, handled in a thread, the editor is then modified and then when the operation is finished, the plugin needs to figure out if the code-completion still applies because another code completion might have come in, it might be identical, it might not be, the same request might be pending, and then you do another one in our own callback handler etc... The amount of cases where it can do something else than the user expects is very high.
Nevertheless it's there, in 16.01 so we'll live with it.
--- End quote ---
The current way when code-completion is requested
1, ccmanager call a function in ccplugin, thus a request is send to ccplugin
2, ccplugin directly return some token list back to ccmanager, thus ccmanager show the results.
EDIT: the asynchronized request is just my idea.
An asynchronized request:
1, ccmanager call a function in ccplugin, thus a request is send to ccplugin
2, ccplugin return a special value(maybe a number), and ccmanager know it will return the results later.
3, ccplugin can do the dirty work in a worker thread
4, when result is out, ccplugin can send a message or call a sdk function from ccplugin
5, the result is shown.
If there are another request in between those steps, we can cancel some steps and do it again, a request can have a number, so they don't conflict.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version