feat: support for ANSI color sequences(#338)

[nowhszh]

Image 1:

Image 2:

[nowhszh]

Currently it's only to show what it looks like after parsing, and it will still take some time before it's merged.

Here is the final plan:

• Cross-line ANSI sequences parsing is not in the plan (Image 1), because saving all the parsing results of a file takes up too much memory space, and cross-line ANSI sequences are a small probability event.
• Only support parsing colors from ANSI sequences.

[variar]

That's a good start! Moving all escape handling to a separate class should make it easier to reuse. In current implementation escape sequences are dropped when reading lines from file. That way searching never sees them. If they are passed to UI and then transformed into actual colors, then they have to be dropped before the line is passed to hyperscan.

One idea to think about -- drop the escape sequences at the same place they are dropped now and construct a set of highlighters that should be applied to that line, could be in raw lines struct. This way there is no need to change search and quickfind code. And AbstractLogView change would be to add any such highlighters to the set.

[nowhszh]

That's a good start! Moving all escape handling to a separate class should make it easier to reuse. In current implementation escape sequences are dropped when reading lines from file. That way searching never sees them. If they are passed to UI and then transformed into actual colors, then they have to be dropped before the line is passed to hyperscan.

One idea to think about -- drop the escape sequences at the same place they are dropped now and construct a set of highlighters that should be applied to that line, could be in raw lines struct. This way there is no need to change search and quickfind code. And AbstractLogView change would be to add any such highlighters to the set.

Thank you very much, I will think about this and give reasons for my final choice!

[nowhszh]

@variar
I simply implement a set of ways to get log data（nowhszh@b138153 ）. The data obtained in this way is more like raw data and it has the following features:

• More freedom of use. Users can process the data in their own way
• Easier to extend. When you need to add a unified way of handling data, you only need to modify the OneLineLog class.
• Reduce the frequency of file reads. Avoid loading data from a file more than once when using data in different formats in the same location.

If you think this approach is OK, I will implement it more completely and apply it in the current PR

[nowhszh]

Development is basically complete.
The next step is to improve the code quality and fix the fatal bugs.

[Junbo-Zheng]

Development is basically complete. The next step is to improve the code quality and fix the fatal bugs.

@nowhszh Can you please show a screenshot of the effect after integration into klogg? I mean according to your the latest PR with klogg.

[nowhszh]

Development is basically complete. The next step is to improve the code quality and fix the fatal bugs.

@nowhszh Can you please show a screenshot of the effect after integration into klogg? I mean according to your the latest PR with klogg.

I can't record on my computer. I'll record on a different computer tomorrow.

[nowhszh]

Development is basically complete. The next step is to improve the code quality and fix the fatal bugs.

@nowhszh Can you please show a screenshot of the effect after integration into klogg? I mean according to your the latest PR with klogg.

Functionality is available in the current commit code, but some code needs to be optimized before the merge is complete

[nowhszh]

@variar developed and tested, please review the code.
The SGRParser feature was developed to be more generic, so it doesn't use the Qt string and container libraries internally. It has a separate repository SGRParser, and perhaps I'll follow up with templates to make it more suitable for klogg.