Here is the first bug. Easy for me to locate because the <after_color_out_char1_not_here> element is generated only if there is a bug.
47: -- ENABLE_...
48:
]]>
</in_buffer>
<in_insert>
<![CDATA[-- Configuring done
]]>
</in_insert>
<before_color linenum="48" lineofs="0"/>
<before_color_in_pending_text/>
<before_color_in_mark linenum="49" lineofs="0"/>
<after_color_out_line linenum="94" lineofs="0"/>
<after_color_out_char1_not_here linenum="94" lineofs="0"/>
<after_color linenum="48" lineofs="0"/>
<before_scroll_mark linenum="49" lineofs="0"/>
<before_scroll_buffer>
Notice that this file has around 48 lines (probably 49 lines) coming into SlickEdit's xterm coloring function. I say around 48 lines because the <in_insert> text has been inserted already but there's not another buffer output element before the xterm coloring for us to see the exact buffer contents. Then after coloring we see <after_color_out_line linenum="94" lineofs="0"/>. This should be impossible. No way the build buffer has 94 lines. This is somehow related to this bug and why the \1 byte is not being removed.
I had to add a lot more debug into SlickEdit's xterm coloring function to further investigate this. Since this next xterm coloring function is generating a lot more debug, I've had to remove some other debug because this stuff is getting crazy large as you've noticed.
Here's installer #4:
http://support.slickedit.com/outbound/2601/se_26000100_linux64_build4_dbg.tar.gzI'm hoping that even if I can't quite understand what is going wrong this time, maybe I can do a mini playback and be able to trace the problem (assuming the problem isn't random). If I had to guess, it seems like the buffer being processed by the xterm color function is getting changed to another buffer. If this is happening, I've got a lot more debug checking for this happening to narrow down where it's happening.