search

santaclose / ImGuiColorTextEdit

Colorizing text editor for ImGui
MIT License
67 stars 18 forks source link

Make boost usage optional #6

Closed ilopit closed 1 year ago

ilopit commented 1 year ago

Hey!

What do you think about making usage boost optional?

santaclose commented 1 year ago

what alternative do you suggest? the std implementation seems not to work properly (Microsoft STL I guess), saw stack overflows many times when running the search function.

ilopit commented 1 year ago

Hmm... I see your point. I am not a fan of regex, can't help. I am just afraid that bringing boost by default will complicate this library.

ilopit commented 1 year ago

maybe we can guard boost with #IFDEFS?

santaclose commented 1 year ago

the thing is, what should we use if not boost regex? We need regex for syntax highlighting. The library was added as a submodule and is being compiled from source, so imo shouldn't really be a problem. Are you having any issues with it?

3O11 commented 1 year ago

I don't fully understand the way regex is used in this code, but if it's really necessary to pull in a dependency, wouldn't it be better to use something like CTRE instead? There would be potential for better performance, and since the library has a single-header version, it could be included directly in the repo, instead of using clunky git features like submodules.

santaclose commented 1 year ago

compile time regex sounds good for syntax highlighting yeah. I might look at it in the future, and you're of course welcome to open a pull request. Why do you think submodules are a clunky feature btw? (just curious)

3O11 commented 1 year ago

I'm planning on looking into it at some point, I just haven't had the time yet, unfortunately. I'll try to implement it and open a pull request when I manage to find enough time.

As for submodules, it's mostly just personal preference, since I've had some issues when using them. Specifically moving them around in the repo, updating the dependencies to new versions, and issues when the submodule path conflicts with an existing directory on a different branch. I usually resolve source dependencies with CMake's FetchContent, but I understand that's not ideal, since it would force the users to use a specific build system.

santaclose commented 1 year ago

thanks for the info!

ilopit commented 1 year ago

Try to use google repo

ilopit commented 1 year ago

I guess we can close it