GNOME Bugzilla – Bug 704108
PHP highlighting treats non-blank line following a comment as a continuation of the comment
Last modified: 2014-08-12 21:03:04 UTC
Created attachment 249021 [details] Screenshot showing issue Originally reported in Fedora: http://bugzilla.redhat.com/983902 With PHP code like this: <?php // Print something if ($test == false) { echo "something"; } echo "done"; ?> The "if" statement looks like a comment, unless there's a blank line after the "// Print something" comment. See attached screenshot.
*** Bug 705988 has been marked as a duplicate of this bug. ***
Thanks for reporting! tested in last SVN the problem appears to be solved.
I can confirm this bug is still present using current SVN on Fedora 19,
are you sure you used a new binary and new language files? I'm pretty sure I fixed this issue.
Confirmed in Ubuntu 13.10, and filled bug report [Bug 1242387] : https://bugs.launchpad.net/bugs/1242387
can anybody confirm if this bug is still reproducible in svn revision 8120? The example above works correctly, so it seems to be fixed.
Created attachment 257918 [details] Example file File attached reproducing the problem with 8121 on Fedora 19.
Created attachment 258144 [details] screenshot with correct line comment highlighting example file shows correct on said revision.
The bug appeared on two pc's running recently upgraded ubuntu 13.10, but before upgrade (ubuntu 13.04) the highlighting was ok.
Created attachment 258218 [details] 8133 showing highlighting error This is with 8133 on a fully updated Fedora 19 system that still shows the error. php.bflang2 is current 8127.
*** Bug 711067 has been marked as a duplicate of this bug. ***
hmm how is this possible? it works on my computer and doesn't on yours.
(In reply to comment #12) > hmm how is this possible? it works on my computer and doesn't on yours. It works ok on my computer with ubuntu 13.04, but in my house computer, upgraded to ubuntu 13.10 the bug appears. Tryed reinstalling via sudo apt-get purge, apt-get install, and downloading sources and compiling. I'm not sure if its a bluefish specific problem. I can give you more info if you need.
it is a bluefish specific problem, which should have been fixed in the latest SVN revision, but apparently the bug is still present.
(In reply to comment #14) > it is a bluefish specific problem, which should have been fixed in the latest > SVN revision, but apparently the bug is still present. sorry haven't tested the SVN version. i'm just jusing the standard ubuntu release versions current 2.2.4 additional info: ./configure '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=${prefix}/lib/bluefish' '--disable-maintainer-mode' '--disable-dependency-tracking' '--with-icon-path=${prefix}/share/pixmaps' '--with-theme-path=${prefix}/share/icons/hicolor' '--with-freedesktop_org-menu=${prefix}/share/applications' '--with-freedesktop_org-mime=${prefix}/share/mime' '--with-xml-catalog=${sysconfdir}/xml/catalog' '--disable-static' '--disable-xml-catalog-update' '--disable-update-databases' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--as-needed' 'build_alias=x86_64-linux-gnu' gtk 3.6.4 (runtime gtk 3.8.4) glib 2.36.0 (runtime 2.38.1) with libenchant... yes with libenchant >= 1.4... yes with libgucharmap... no with libgucharmap_2... yes with python... yes
Olivier, if you are not seeing this problem now, what are running Bluefish on? Did you check to make sure that you don't have any uncommitted files to svn? Since a lot of people are seeing this after a Ubuntu upgrade could this be because of a change in behaviour in GRegex or possibly a change in the version of PCRE that Glib is compiled against?
Two questions: 1) can somebody with this problem on latest SVN send the contents of their ~/.bluefish directory to see if it is related to some setting? 2) can somebody on latest SVN edit bftextview2_private.h and set #define DBG_SCANNING g_print recompile, and post the full terminal output after loading the simple example from the original bugreport: <?php // Print something if ($test == false) { echo "something"; } echo "done"; ?> I hope this gives some clues why this goes wrong (and why I cannot reproduce it). I don't think it is related to the Ubuntu upgrade, besides that bluefish is upgraded to a different too ;-) (I test on Ubuntu 12.04 and 13.10)
Created attachment 258851 [details] Terminal output Terminal output is attached
can somebody check if it also reproducible with the "shell" syntax scanning, with "Coreutils" disabled? that language file is much smaller, and as such easier to debug. I'm looking for a minimal file that displays the problem with a minimal language file. I still don't understand why I cannot reproduce it. I have tried 4 computers with different gtk/glib versions....
Created attachment 258975 [details] incorrect shell highlighting Attached is incorrect highlighting of a shell script, Coreutils disabled. If I add a blank line after the comment line, it will highlight correctly.
Simple three line test that I tried # test comment aaaa="$(dirname "$Env")" RTadmin="$(dirname "$aaaa")"
ok, I've added more debug output in revision 8136 I'm especially interested in the ouput of the DFA table: ***************** print subset of DFA table for context 3 '#' 'a' ' ' \n \r ': match 0: 1 1 1 2 3 0 : 0 1: 1 1 1 0 0 0 : 0 2: 0 0 0 0 0 0 : 180 ( | ) 3: 0 0 0 4 0 0 : 180 ( | ) 4: 0 0 0 0 0 0 : 180 ( | ) and the resulting scanning around offset 14 scanning offset 13 pos 1 't'=116 (context=3).. got newpos 1 scanning offset 14 pos 1 ' '=10 (context=3).. got newpos 0 -> symbol or pattern itself ends on symbol no match, but do set mstart to offset 14 and set newpos=0 scanning offset 14 pos 0 ' '=10 (context=3).. got newpos 2 scanning offset 15 pos 2 'a'=97 (context=3).. got newpos 0 -> symbol or pattern itself ends on symbol we have a match from pos 14 to 15 found_match for pattern 180 ( | ) at charoffset 14, starts_block=0,ends_block=0, nextcontext=-1 (current=3) found_match, apply tag 0x1e2b850 from 14 to 15 no nextfound, so enlarge scanning region to end iter found_context_change, should pop 1 contexts, curfcontext=0x3008700 pop_and_apply_contexts, end context 3 at 1:14, has tag 0x1e2b850 and parent (nil) after match context=1 scanning offset 15 pos 0 'a'=97 (context=1).. got newpos 46
Created attachment 259013 [details] incorrect shell highlighting 8136 This is the same three line test with 8136. Don't know if it helps but I'll attach 8136 with an extra blank line after the comment line that has the correct highlighting.
Created attachment 259014 [details] correct shell highlighting 8136
just a heads-up (from the sideline), when i create a script save it and reopen it the highlighting is off. when i do an enter or an space at the end (of a line, or at the end of a comment) it will correct the highlighting. but after saving and reopening the highlighting is off again. don't know if it helps, but i saw the suggestion mentioned before and wanted to prevent you from going the wrong way.
That is interesting. For me, as long as the blank line is after the comment line I can close, reopen the file and the highlighting will still be correct.
well as mentioned before, i'm not using SVN. i'm using the standard released Ubuntu 2.2.4 so sorry if it throws you off. but i thought it would help you pin point the problem.
I managed to reproduce it (I installed Fedora 19), and I seem to have fixed the issue in revision 8137, but I really don't understand what was going wrong. the loop at bftextview2_patcompile.c line 520 for (j = 0; j <=NUMSCANCHARS ; j++) ran far beyond 127 (the value of NUMSCANCHARS) which caused the incorrect state table. how on earth could j get larger than 127 ????? very weird... please test revision 8137 and let me know if the problem is fixed.
I think this is because you had an out-of-bounds array access: The maximum index of the array "characters" is NUMSCANCHARS - 1, yet you let the loop run until NUMSCANCHARS. Replacing "j <=NUMSCANCHARS" with "j < NUMSCANCHARS" should work. Newer GCC use very aggressive loop optimizations. The manpage notes: "This assumes that loop code does not invoke undefined behavior by for example causing signed integer overflows or out-of-bound array accesses. The bounds for the number of iterations of a loop are used to guide loop unrolling and peeling and loop exit test optimizations." So the problem should also disappear if you compile with -fno-aggressive-loop-optimizations. Also, I think there are warnings in -Wall that should catch such errors. Are you compiling with warnings?
thanks, fixed in revision 8139. I've started so long at the screen today, but I didn't check the size of the array.. I do always compile with -Wall and I didn't see a warning... :(
(In reply to comment #29) > I think this is because you had an out-of-bounds array access: The maximum > index of the array "characters" is NUMSCANCHARS - 1, yet you let the loop run > until NUMSCANCHARS. > > Replacing "j <=NUMSCANCHARS" with "j < NUMSCANCHARS" should work. > This actually does fix 8136.
*** Bug 711644 has been marked as a duplicate of this bug. ***
Works for me, and for the original reporter in Fedora bugzilla.
*** Bug 721922 has been marked as a duplicate of this bug. ***
Downloaded v2.2.5b2 and built RPM. Installed on openSUSE 13.1 and the PHP highlighting is working now. Thanks!
(In reply to comment #35) > Downloaded v2.2.5b2 and built RPM. Installed on openSUSE 13.1 and the PHP > highlighting is working now. Thanks! Hmmm ... I dunno if I must file this as a new bug, but let me first state something new I noticed in the v2.2.5b2. Doc type is *.phtml: 1. Set Bluefish->Document->Language Mode->PHP then PHP code inside the HTML <!-- --> comments are not greyed out. 2. Set Bluefish->Document->Language Mode->Generic HTML then PHP code is not highlighted. HTML code is.
*** Bug 722830 has been marked as a duplicate of this bug. ***
It now works fine on updated Fedora 20. The bug is still in updated Mageia 4, but this is because of Mageia policy to update only for security reasons: the version is still 2.2.4 there.
We cannot fix it in Mageia unless they want to backport this fix..