Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Several improvements to Code Completion plugin
oBFusCATed:
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Updated the code for detecting whether the mouse pointer is over a selected text. The original code was just a simple approximation, this one does a proper test.
--- End quote ---
Can you provide the steps, where the old one failed?
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Fixed both code completion tooltip and debugger tooltips appearing at the same time (it happens if debugger tooltip takes some time to compute and display). Several tests are done before displaying the debugger tooltip, one of which is supposed to avoid this bug from occuring. I've fixed the order in which those tests are done.
--- End quote ---
This is more of a black magic, not science, but I'll see if it makes a difference.
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Do not show the debugger tooltip when Ctrl key is pressed (i.e., if "Only show tooltip when Ctrl key is pressed" option is turned off - the default, we now do the opposite).
--- End quote ---
I still don't understand...Steps to reproduce?
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Debugger stalls when trying to step into unknown code (or even a return statement). See this thread.
--- End quote ---
I think this is fixed already. Are you able to reproduce the problem without this patch using latest trunk?
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Setting the working directory for debugger fails for me, tracked it down to wxSetWorkingDirectory() which fails if the path is converted to GDB format. Removing the ConvertToGDBDirectory(path); fixes it.
--- End quote ---
Hm, I'm not sure if this is not going to break something else...
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---thread_search:
- Do not automatically prepend the tilde sign if found. Users can still select the text including the ~ if they wish to include it in the search text. I have seen several cases where the tilde is used as the bitwise NOT operator, so shouldn't always assume for C++ destructor. I've also done similar fixes in Code Completion plugin.
--- End quote ---
It sounds like we need to move the cbDebuggerPlugin::GetEditorWordAtCaret to the EditorManager class, so all plugins can reuse it or in cbPlugin...
Huki:
--- Quote from: oBFusCATed on September 08, 2013, 11:26:29 am ---
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Updated the code for detecting whether the mouse pointer is over a selected text. The original code was just a simple approximation, this one does a proper test.
--- End quote ---
Can you provide the steps, where the old one failed?
--- End quote ---
When a line is not fully selected, the old test would detect the unselected parts of the line as selected and display tooltip on it (we only want to display debugger tooltip on the selected text).
--- Quote ---
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Fixed both code completion tooltip and debugger tooltips appearing at the same time (it happens if debugger tooltip takes some time to compute and display). Several tests are done before displaying the debugger tooltip, one of which is supposed to avoid this bug from occuring. I've fixed the order in which those tests are done.
--- End quote ---
This is more of a black magic, not science, but I'll see if it makes a difference.
--- End quote ---
Hmm no, we need to make sure the "get rid of other calltips" is the first test to be done. If there are any tests done before it, and they already fail and return, the existing tooltips never gets canceled, hence the bug.
--- Quote ---
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Do not show the debugger tooltip when Ctrl key is pressed (i.e., if "Only show tooltip when Ctrl key is pressed" option is turned off - the default, we now do the opposite).
--- End quote ---
I still don't understand...Steps to reproduce?
--- End quote ---
This one not a bugfix, I've added a small feature: press and hold Ctrl key to temporarily disable the debugger tooltip.
--- Quote ---
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Debugger stalls when trying to step into unknown code (or even a return statement). See this thread.
--- End quote ---
I think this is fixed already. Are you able to reproduce the problem without this patch using latest trunk?
--- End quote ---
When I updated to rev 9271 I noticed there was an attempt to fix this. I haven't tested if it works. I still found my modification relevant (I commented that part). RunQueue() is already called at the end of the procedure, so we'd better flag the m_ProgramIsStopped, and let RunQueue() reset it if required.
--- Quote ---
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Setting the working directory for debugger fails for me, tracked it down to wxSetWorkingDirectory() which fails if the path is converted to GDB format. Removing the ConvertToGDBDirectory(path); fixes it.
--- End quote ---
Hm, I'm not sure if this is not going to break something else...
--- End quote ---
I can confirm the path is only used with wxSetWorkingDirectory(), never sent to GDB. So at least for now it should be safe to remove ConvertToGDBDirectory();
Huki:
--- Quote from: Huki on September 08, 2013, 06:06:46 pm ---
--- Quote from: oBFusCATed on September 08, 2013, 11:26:29 am ---
--- Quote from: Huki on September 08, 2013, 03:30:44 am ---- Updated the code for detecting whether the mouse pointer is over a selected text. The original code was just a simple approximation, this one does a proper test.
--- End quote ---
Can you provide the steps, where the old one failed?
--- End quote ---
When a line is not fully selected, the old test would detect the unselected parts of the line as selected and display tooltip on it (we only want to display debugger tooltip on the selected text).
--- End quote ---
Additional info: the old test simply takes a rect from selection start to selection end, so it gives incorrect results when selecting multiple lines. I've attached some screenshots below - the red rectangle shows the incorrectly detected selection block. It's something that bothered me when I was selecting text (to copy, etc) and noticed the tooltip appearing behavior was not consistent.
I also checked if any of my other patches were in need of explanation:
scintilla_fixes: In LexerCPP::Fold(), fixed folding glitch in case of hanging braces in a preprocessor block. Eg,
--- Code: ---#ifdef _DEFINE
if (condition1) {
#else
if (condition2) {
#endif
...
}
--- End code ---
jump_tracker: More consistent behavior for Jump Tracker (cursor history navigation) feature (View -> Jump -> Jump Back / Frwd - I set Ctrl - Left / Right shortcuts for it as it's a very useful feature for me :) ).
incremental_search: Fixed search history flooding. Eg, when typing "codecomp" in the search box, it used to record in history:
--- Code: ---c
co
cod
code
...
--- End code ---
The rest of patches are CC related...
cc_fix_tokenizer: In Tokenizer::ReadToEOL(), which is used by HandleDefines(),
--- Code: --- //FIX(huki) if (ch <= _T(' ') && (p == buffer || *(p - 1) == ch))
if (ch <= _T(' ') && p > buffer && *(p - 1) == ch)
--- End code ---
i.e., do not remove the leading space. This is to differentiate defines containing brackets, from legitimate macros. Eg,
--- Code: (This is a macro) ---#define MYMACRO() ...
--- End code ---
--- Code: (This is NOT a macro) ---#define MYDEFINE (A + B)
--- End code ---
The fix in Tokenizer::ReadParantheses() support '==' (previously it was taken as two assignments, i.e., ' = = '.
Rest should be commented already in the patch.
oBFusCATed:
One note:
Scintilla fixes should go to the Scintilla project first.
Here we do use a modified Scintilla, but we prefer not to diverge too much from upstream Scintilla.
It eases the upgrade of the component a lot.
Also I think your wxDynamicLib modification to (wx)Scintilla are too much and we cannot accept them (this is my opinion and others should speak, too, especially Morten as he is the maintainer of this component in C::B).
You'll have to find another way to do it. Probably consulting with Scintilla devs for a way to do it or to ask them to add some API that will suit you.
oBFusCATed:
--- Quote from: Huki on September 08, 2013, 10:14:57 pm ---Additional info: the old test simply takes a rect from selection start to selection end, so it gives incorrect results when selecting multiple lines. I've attached some screenshots below - the red rectangle shows the incorrectly detected selection block. It's something that bothered me when I was selecting text (to copy, etc) and noticed the tooltip appearing behavior was not consistent.
--- End quote ---
Understood and I was able to reproduce it. Also I was able to implement it in a simpler way:
--- Code: --- int startPos = stc->GetSelectionStart();
int endPos = stc->GetSelectionEnd();
int mousePos = stc->PositionFromPointClose(mousePosition->x, mousePosition->y);
if (mousePos == wxSCI_INVALID_POSITION)
return wxEmptyString;
else if (startPos <= mousePos && mousePos <= endPos)
return selected_text;
else
return wxEmptyString;
--- End code ---
Can you try if this snippet fulfils all your requirements?
BTW: Thank you for you contribution, it is appreciated.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version