Hiccups while typing (continuation)

[Elena]

Since some months (not sure from which NB the problem started, unfortunately) I noticed there are annoying hiccups while editing code in the main text editor. In the meantime I tried disabling the following (on suggestion):
-Browse Tracker plugin (this improved slowness overall a lot though)
-Thread Search plugin (this likely improved the hiccups but not completely)

In particular, I suspect they are related to a plugin whose name I ignore, which is responsible for those two choosers (pop-down menus) in the top bar, which show all symbols defined in the current code. In fact, I notice that when such hiccups occur, those two choosers are displayed ghosted (disabled) for a fraction of a second and then become enabled again.
Btw, which is the plugin responsible for those, so that I can try disabling it, to see if the hiccups disappear ?

Using latest NB, Win10 x64.
Thx

[Pecan]

Well, I'm sorry that BrowseTracker is not working for you.
But I do not know what else I can do since I cannot re-create the slow down hiccups.

BTW, what kind of machine are you using?
Are you using a system with an Intel Celeron?

Regarding the plugins that use popup windows and show code selections would be CodeCompletion and clangd_client.

CodeCompletion and cland_client are multi-threaded and require heavy usage of the cpu. You might want to disable them and see what happens to the hiccups.

[Elena]

Hi Pecan,
my PC is an Intel i7 8700K 3,7 GHz, a very fast machine.
As I said, those "hiccups" started at some point, I would say between last Spring and Summer, sadly I can't say for sure from which Nightly Build But everything was fine and smooth before that point !

The clangd client is already disabled.
As for the Browser Tracker, I was suggested here to disable it, by another user who experienced slowdowns by it on startup (but it was not responsible for the hiccups while typing).
As for the Thread Search (another thing which was suggested here) I disabled it but I don't think that helped with the hiccups.

I tired to disable the Code Completion, but it was NOT the culprit.

Those little hiccups are noticeable in particular while moving the cursor thru the text.

As I said, I think the culprit is the plugin responsible for showing those two choosers in the top bar, with all functions defined in the current code. But I don't know which plugin it is, so I cannot try disabling it...

[Pecan]

... In fact, I notice that when such hiccups occur, those two choosers are displayed ghosted (disabled) for a fraction of a second and then become enabled again.
Btw, which is the plugin responsible for those, so that I can try disabling it, to see if the hiccups disappear ?

Using latest NB, Win10 x64.
Thx

I'm unclear about which "two choosers" you mean.
Are they one of the menu choices, or one of the icon choices? Do they have a name that pops up if you hover the mouse over them?

If we could get closer to which "choosers", we can get closer to the problem.

Are you just hovering over some variable in the text when it happens.
Could you give me a "1)do this" then "2)do that" type instructions to get a clearer picture in my old mind?

[Elena]

Hi Pecan, I am sorry if I really cannot be more accurate.
I have attached a screenshot of those I call "choosers", very sorry for not having a better name for them lol
Which plugin is responsible for them btw ?
Unfortunately there are not any definite actions I can suggest to reproduce the hiccups
But I notice clearly, when moving the cursor thru the text, or sometimes while typing, that often very short pauses occur, fractions of a second I mean, but are annoying and noticeable and can still be confusing if one types or edits quickly. And when this happens, for a very short time those two gadgets flash or kind of, like they becoming disabled and then enabled again, so I suspected it could be related.
Again, I started noticing this problem at some point last Summer.

[Pecan]

... for a very short time those two gadgets flash or kind of, like they becoming disabled and then enabled again, so I suspected it could be relatedT

Thanks for the screenshot
.
Those are the Scope and function/variable choice boxes for the plugin Code Completion.

Go to MainMenu>plugins>ManagePlugins  and disable the plugin "Code completion", restart CB, and see if the hiccups disappear.

If that eliminates the hiccups re-enable "Code completion" and restart CB.

Now go to MainMenu>settings>Editor>CodeCompletion> and disable "update parser when typing" check box. See the attached screenshot. Tell us if that eliminate the hiccups.

Also check (at bottom of Code completion settings) "Delay for Auto-kick-in when typing". Raise to at least 300 millisecs or until the hiccups disappear.

Look, also, at the second screenshot (Editor settings) and make sure the kick in for Code completion is set at (say around) 3 letters.
 

[Elena]

Hi Pecan,  thanks for your support !
Disabling Update Parser When Typing seems to have fixed the hiccups !
Re: the other two settings suggested were already 300 ms and 3

[Elena]

Oh what's up, a bug ?
It seems that if I close C::B and I reopen it, the "Update parser when typing" setting gets enabled again ! Can you check ?
NB svn 13598

[Pecan]

Oh what's up, a bug ?
It seems that if I close C::B and I reopen it, the "Update parser when typing" setting gets enabled again ! Can you check ?
NB svn 13598

Yes, it's a bug. When CB is closed with a project active, a new setting of "Update parser..." will toggle itself.

When CB is closed with no project active, then "Update parser..." is changed,the "Update parser..." will hold.

So..., when I close all projects, change the "Update parser..." then close CB, the status of the check box will hold.

Weird !

Edit: 12:48 pm
When closing with no project open the CC parser is not involved.
When closing with a project open, the parser at 928 writes the value it was constructed with, not the updated value from the settings dialog.

cfg->Write(_T("/while_typing"), m_Options.whileTyping); //(ph 2025/02/03) wrong value when calledfrom ClassBrowser 245

Called from ClassBrowser 245: m_Parser->WriteOptions();
m_Options.whileTyping has the value before it was changed in settings dialog.

What I don't understand is why ClassBrowser has a stale value of the "Update parser..." value. In .conf it's named <WHILE_TYPING bool="0" />

[ollydbg]

If I remember correctly, it is a known bug for a long time. But I nearly forgot the details.

I just remember that: Each Parser instance(for each cbp projects) has there own CodeCompletion options, and when you saved the CodeCompletion options, it is only for the active Parser instance. But if you don't have any cbp file opened, there is still a special hidden Parser instance created for "dummy cbp projects".

[ollydbg]

Code

// ----------------------------------------------------------------------------
void ClassBrowser::SetParser(ParserBase* parser)
// ----------------------------------------------------------------------------
{
    if (m_Parser == parser)
        return;

    m_Parser = parser;
    if (m_Parser)
    {
        const int sel = XRCCTRL(*this, "cmbView", wxChoice)->GetSelection();
        BrowserDisplayFilter filter = static_cast<BrowserDisplayFilter>(sel);
        if (!m_ParseManager->IsParserPerWorkspace() && filter == bdfWorkspace)
            filter = bdfProject;

        m_Parser->ClassBrowserOptions().displayFilter = filter;
        m_Parser->WriteOptions();
        UpdateClassBrowserView();
    }
    else
        CCLogger::Get()->DebugLog("SetParser: No parser available.");
}

It looks like the "last Parser's option" is written to the configure file.

So, can we add a check here in the line 245 of the file: plugins\codecompletion\classbrowser.cpp

I mean if it is a dummy parser(temp parser), we won't need to save the parser's option?

Because when a cbp project get closed, the dummy parser is always active, so the dummy parser's option is always saved when I close the C::B. (But this has some issue, when user open C::B without opening any cbp file, all the option is saved to dummy parser)

Another method is that we can copy the option of a closed project to the dummy parser's option, so that the dummy parser's option will be the same as the last cbp project's option when get closed.

[Elena]

For me, the only way for the option to stay un-checked is opening C::B with no projects, un-checking it, closing C::B. Every project opened then will maintain the setting.

[ollydbg]

When the workspace get closed(in the workspace close event handler), the below function will be called:

Code

bool ParseManager::DeleteParser(cbProject* project)
{
    wxString prj = (project ? project->GetTitle() : _T("*NONE*"));

    ParserList::iterator it = m_ParserList.begin();
    if (!m_ParserPerWorkspace)
    {
        for (; it != m_ParserList.end(); ++it)
        {
            if (it->first == project)
                break;
        }
    }

    if (it == m_ParserList.end())
    {
        CCLogger::Get()->DebugLog(wxString::Format("ParseManager::DeleteParser: Parser does not exist for delete '%s'!", prj));
        return false;
    }

    bool removeProjectFromParser = false;
    if (m_ParserPerWorkspace)
        removeProjectFromParser = RemoveProjectFromParser(project);

    if (m_ParsedProjects.empty()) // this indicates we are in one parser per one project mode
    {
        wxString log(wxString::Format(_("ParseManager::DeleteParser: Deleting parser for project '%s'!"), prj));
        CCLogger::Get()->Log(log);
        CCLogger::Get()->DebugLog(log);

        // the logic here is : firstly delete the parser instance, then see whether we need an
        // active parser switch (call SetParser())
        delete it->second;

        // if the active parser is deleted, set the active parser to nullptr
        if (it->second == m_Parser)
        {
            m_Parser = nullptr;
            SetParser(m_TempParser); // Also updates class browser
        }

        m_ParserList.erase(it);

        return true;
    }

    if (removeProjectFromParser)
        return true;

    CCLogger::Get()->DebugLog(_T("ParseManager::DeleteParser: Deleting parser failed!"));
    return false;
}

Note that there is a line:

Code

SetParser(m_TempParser); // Also updates class browser

In this case, the dummy parser is set as the "active parser". So, in the final stage, this dummy parser's option will be saved to the config file, not the last active project in the workspace.

[Pecan]

@ ollydbg

I'll test out your suggestions today. Thanks.

I'll test with NO project, then one, then multiple projects and see if checking for the dummy (first) parser works.

Another thought might be to issue a shared event to tell all parsers to re-read (update its parser.options) if a user clicks OK in the CodeCompletion settings dialog.

I don't mean to create a new global event, but I know that an event using an XRCID("mySharedEventId") is possible if both sender and receiver use the same XRCID.

[Pecan]

@ ollydbg

How about this idea.

The ccoptionsdlg can always record, in a global var, the address of the active parser that last updated the settings.

When the workspace is closed, if that var contains an address, that parser will be the only parser that is allows to update the .conf settings.

That way, any number of projects can be in the workspace, but only the last parser to update the settings can finally store them to the .conf .

Wouldn't that work for only one parser and also for multiple parsers?

If the global var is nullptr, ccoptionsdlg never got called to change any option, then we don't care about which parser updates the .conf .

ccoptionsdlg would only set the active parsers address in the global var, if the user clicked OK to dismiss the dialog.
I'm assuming that the dismiss dialog action (OK or Cancel) can be caught.
Else we'd have to find another way to determine that the user changed any option.

Edit: 10:35am
Got It. void CCOptionsDlg::OnApply() is only called when user clicks OK. I'm thinking that's the only place we need to set the global var with the active parser address.



Is all this true?