Does this happen when you are not typing next to closing parenthesis ?

Also, could you check if the "match brace" is set to "Bold" for you?
You can check this here:
settings -> colours and fonts-> customised tab -> Styles tab

And select the style: "Brace match"

I made small gif image that shows the issue (not a regression), previously it was there but CodeLite did not support bold font - so you never saw this. However, I could notice that sometimes that the typed char was "yellow" before it was painted properly (this existed before)

To make this more noticeable, I changed the "Match brace" style to "Italic" and typed 1 - you can immediately see that the typed char is made italic and quickly after that it fixes itself.

Does this happen when you are not typing next to closing parenthesis ?

You are absolutely spot on! The issue occurs right to the braces and it seems that typed characters are first considered as part of the braces before changing color. I also noticed that while moving cursor around, the matching braces take some time to appear/disappear which could be related to this.

This is why:

https://github.com/eranif/codelite/blob/master/LiteEditor/cl_editor.cpp#L6453

I limit the number of idle events to 4 in a second (for performance). You can reduce it value to 100 this will give you a sense of more responsiveness

I committed a fix that should increase the responsiveness

I limit the number of idle events to 4 in a second (for performance). You can reduce it value to 100 this will give you a sense of more responsiveness

How do other Scintilla-based editors like Notepad++ handle this? Do you happen to know? Also, wouldn't a wxWidgets Scintilla version newer than 5.0.0 squeeze more performance out?

V5 is the most recent wxWidgets has.

There are 3 ways of doing this:

• OnScintillaUpdate event
• OnTimer - create a custom timer that fires every N milliseconds
• OnIdle - in an idle event, in this case you will have to throttle it a bit to avoid too much CPU consumption

A common sense would suggest to start analyzing for brace matches in a separate thread as soon as some character is typed rather than waiting some time interval. On a relatively fast system like mine with Ryzen 7 9800X3D CPU the result should be instantaneous: as you continuously move the cursor with arrow keys, the matching braces should appear and disappear accordingly as the cursor passes between them. However, now even with the fix, I have to let the cursor sit to let matching braces show up.

But I don't know how CodeLite detects matching braces, maybe it is more complicated having to deal with clang, etc. I suppose initial timeout of 250 ms was chosen as a balance measure for #3210?

P.S. The issue of bold letters as described in top post still persists as of latest commit 562ed4c.

The problem with GUI (all of the frameworks: WinAPI, GTK & Cocoa) is that they are all none thread safe, i.e. the background thread can not access the UI elements (which makes things a bit more problematic)

@yunkot I committed a fix - that should fix this.

Please try it locally - make sure to update the submodules as well:

git pull --rebase --recurse-submodules
# build codelite

Is the fix for terminal colors or bold typed characters? After updating, now CodeLite crashes each time when closing it.

Terminal colours, I did not experience the crashes here, will try different OS..

I've deleted ".codelite" configuration directory and now CodeLite even crashes when trying to restart at first run.

@yunkot I committed a fix - that should fix this.

Regarding the console output colors - this issue seems to be fixed, many thanks!
Anything I can do to help debugging the crash / regression?

Already fixed. Do git pull 😄

I did not see the crash earlier because I am using wx3.3 ...