I'm encountering an issue with text rendering when using an external font. The original branch displays the text correctly and functions as expected. However, when I switch to the fork branch, the text alignment appears to be different, causing inconsistencies in the rendering.

Steps to Reproduce:

Switch to the original branch and observe the text rendering with an external font.
Switch to the fork branch and compare the text alignment with the original branch.
Notice the differences in text alignment between the original and fork branches.
Additional Details:

The external font being used: Robotto.ttf
Screenshots showcasing the issue on both branches:

santaclose:

BalazsJako:

This issue affects the consistency and appearance of the text rendering, particularly when using external fonts.

Commit eab54a3 stops updating the palette every frame and added a new default palette interface.

While speeding up the rendering loop is always a good idea, this change causes two side effects that are now hampering me:

• The ability to have a custom color palette, which I was using, is now lost.
• Changes to ImGui::GetStyle().Alpha are no longer automatically handled. In one of my applications, I give the user control over the transparency of the GUI and I now have to set a new palette on the editor every time they change transparency.

My implementation at goossens@d738eaf achieves the same thing you were after without the side effects.

It also maintains backwards compatibility for those who quickly want to change over from the old library to yours. 😄

At some point, the ability to render tabs as short arrows was removed from this fork. As a user of Visual Studio Code, I like this feature as it make the editor look cleaner.

In commit goossens@efe2c55, I’ve added it back in to my fork with configurable setting (default is off). Recommend you consider putting it back into this fork.

Let me know if you want a pull request.

This widget seems to assume UTF-8 bytes are always correct, so when it encounters a broken UTF-8 sequence it crashes on this line (if the byte is on the end of the line): https://github.com/santaclose/ImGuiColorTextEdit/blob/76d9ff0d22e89c8e4e93d0cf5e40f8af3def19a8/TextEditor.cpp#L1234C3-L1234C3

Commit 0226e18 (show matching brackets) is a wonderful feature that I already had in my fork and it’s great to have it here. Unfortunately, there is a bug since it doesn’t handle empty lines correctly when it’s finding matching brackets.

Commit goossens@6ff7321 in my fork fixes the problem and as a bonus, it makes the “show matching brackets” optional.

Let me know if you want a pull request.

In my old fork of ImGuiColorTextEdit, I had a feature to autocomplete paired glyphs. So when typing [, {, (, “ or ‘, the matching glyph was also added. Undo removed both characters. The feature is configurable and the default is off.

I have ported this feature to this fork and you can see my changed at goossens@66d8c59. Let me know if you want a put request.

Let me know if you want a pull request.

In issue #6, there was a discussion on making the use of the boost::regex library optional. I have two project where I’m using ImGuiColorTextEdit. In the first one, I’m using regex-based syntax highlighting and using boost is not an issue. I’m doing another project with someone who is very allergic to anything boost and we’re not using regex based syntax coloring.

To support both scenarios, we changed one line in TextEditor.h to six lines and now everybody can be happy.

Change:

#include <boost/regex.hpp>

to:

#ifdef IMGUI_EDITOR_NO_BOOST
    #include <regex>
    namespace boost = std;
#else
    #include <boost/regex.hpp>
#endif

Those that want to use boost don’t have to do anything. Those that are allergic to boost or don’t care for another dependency, can define IMGUI_EDITOR_NO_BOOST in their Makefile or whatever IDE that are using.

You can see my implementation at goossens@9566688. Let me know if you want a pull request.

Hey!

What do you think about making usage boost optional?

When IMGUI_DISABLE_OBSOLETE_FUNCTIONS is enabled, the text editor fails to compile.

This is not really an issue but more of a philosophical discussion to get feedback on the way forward.

Like many other people, I’ve been frustrated with the state of ImGuiColorTextEdit. The original author doesn’t have the time to work on it and the many forks are all over the place. I contributed to this mess by creating my own fork and i did a sort of best of class integration of the various ideas. I was never satisfied with it since a number of fundamental problems/bugs were still around.

This forks seems to be the most promising so I’m going to start using it. Unfortunately, I’m already relying on features of the original that are no longer available as well as ideas I’m using from other forks. I have therefore started a new fork (based on this one) at https://github.com/goossens/ImGuiColorTextEdit so I can keep track of changes and patches.

To have a proper discussion on the things I need, I’ll raise an issue for each topic so we can see if you want to integrate it in your repository. I’ll will also link to the commits in my fork for clarification and if desired, I’ll create a pull request.

Let me know what you think.

Nice work bro.Does this project support Chinese input？

Nice work bro. How about adding xml and yaml?

When creating a language definition, after setting up all the keywords and identifiers, if I set the mCaseSensitive member of the LanguageDefinition struct to true (assuming my keywords and identifiers are in lowercase) the syntax highlighting works perfectly, as shown below:

But, when I switch it to false, I expect it to highlight both the uppercase and lowercase identifiers in the same way, but it does not do that and syntax highlighting just stops working, as shown below:

I suspect it has something to do with this line:

But I'm not entirely sure.

Hi, aim trying to achieve a simple ImGui multiline input text with support for word wrapping. No scrolling (auto-grow vertically), no syntax highlighting, no line numbers, just editable text. Is this possible with this control? Is it suitable for that?

If so I need multiple of those on my screen. Can I expect performance close to the ImGui's built-in Text Input with all visual features turned off?

Thanks for the great work.

I can’t compile the current version due to errors in the rewrite of FindWordStart and FindWordEnd. When those methods were changed in commit 6ee401b to use the new Move method, the aFront calling parameters is changed although it’s declared as a const reference. I’m surprised the Windows compiler allowed it (even with the type cast).

The offending lines in FindWordStart and FindWordEnd are the ones with the Move calls like:

while (Move((int)aFrom.mLine, charIndex, true, true))

My simple fix was to use the same pattern that was already used in the (now deleted) FindNextWord method. You can see my change at goossens@583fc70.

At some point, error and breakpoint highlighting were removed from this fork. In my use of ImGuiColorTextEdit, I used these features so I’m now stuck.

Given that the color palettes still have colors for these features, I’m not sure if you are planning to bring them back later or if you forgot to remove the colors.

So before I go reimplement these features in my own fork, what is your plan in this area?