Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I am using 0.9.8.
I am having an issue with the display of source code. Specifically I am seeing this:
<span class='reserved'>voidspan> instead of <span class='reserved'>void</span>
The actual html is:
<<a class='fid' href="/lxr/ident?i=span">span</a> class='<a class='fid' href="/lxr/ident?i=reserved">reserved</a>'>void</<a class='fid' href="/lxr/ident?i=span">span</a>
This happens with Python, C++ and .h files. I assume it happens with all languages as it is happening with the ones I have looked at and care about in my source code repo.
I have been looking at the reserved words in generic.conf and processreserved in Generic.pm but unable to figure out the problem is.
Any pointers would be appreciated.
I stumbled into the same trouble and work on it. I patched my 0.9.8 with Mengel's patch but it does not seems satisfactory.
The mess is caused by the fact that sub processcode in Generic.pm tags symbols in 2 passes: first the reserved words with processreserved and second with a loop to replace the identifiers.
What happens is the call to processreserved has modified the input buffer which now contains HTML tags and the loop makes no difference between the original symbols and the added HTML.
Mengel's patch tries to circumvent the bug by fidgetting with the regexp at the head of loop but as he says himself, it does not solve all the cases. Moreover, it is vulnerable to a change in tagging made by processreserved.
My present idea is to have both processes made simultaneously by inlining processreserved in the loop, so that both transformations are mutually exclusive. This could be generalized to more then 2 processes.
However, it introduces a maintenance vulnerability: if processreserved is modified, you must also modify in the same terms processcode. But there is already such a vulnerability with untabify being inlined in nextfrag of SimpleParse.pm.
As soon as I am confident in my patch (because this is my first contact with Perl), I'll post it.
Same mess may happen if #include file is the same as (or contains) a reserved keyword. Happens only when name of file is surrounded by " (double quotes) or <> (angle brackets), because we have 2 passes: 1/ mark reserved keywords, 2/ tag file name for link.
Does not happen with other syntax, e.g. in Perl, since only "file" and <file> are tagged.
I'll address both issues with my patch.
Erratum to my last comment:
We have in fact 3 passes in processinclude, which makes matters even worse.
I have reliably (I think) corrected this bug and some others. I have posted the whole bunch of patches on the Help Forum under topic Help (wanted) on non-regression after modifications. I'd be glad if you could test them and confirm it really corrects the bug.