Hi August, On 2011-10-02 at 20:00 -0400, August Sodora wrote:
> Apparently the issue was that I actually wasn't using the parameter :) > I've attached a preliminary patch (my first!) for review. Great stuff, thank you for that! :-) Unfortunately the original code is a kind of horror, and there is one tricky thing in there: @@ -266,10 +266,8 @@ sal_Bool SbiScanner::NextSym() // replace closing '_' by space when end of line is following // (wrong line continuation otherwise) if( !bUsedForHilite && !*pLine && *(pLine-1) == '_' ) - { - aSym.GetBufferAccess(); // #109693 force copy if necessary *((sal_Unicode*)(pLine-1)) = ' '; // cast because of const - } + // type recognition? // don't test the exclamation mark // if there's a symbol behind it The (C-style) cast touches the [potentially shared!] pLine (ie. aLine); in which case, when it is shared with aSym, it can break badly when you remove the GetBufferAccess. If we want to get rid of that, I am afraid more refactoring is needed :-( BTW, another horror in the original code is: > ch1 = aSym.ToUpperAscii().GetBuffer()[0]; ie. we convert the entire string to upper case, and then throw all that away but the first char. Can you have a look at these, and maybe first address the ToUpperAscii part, and then have one more look at how to get rid of the GetBufferAccess? Either way - thank you a lot for looking into this! All the best, Kendy _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice