After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704108 - PHP highlighting treats non-blank line following a comment as a continuation of the comment
PHP highlighting treats non-blank line following a comment as a continuation ...
Status: RESOLVED FIXED
Product: bluefish
Classification: Other
Component: language files
2.2.4
Other Linux
: Normal normal
: 2.2.5
Assigned To: Bluefish Maintainer(s)
Bluefish Maintainer(s)
: 705988 711067 721922 722830 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-07-12 15:38 UTC by Paul Howarth
Modified: 2014-08-12 21:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot showing issue (89.17 KB, image/png)
2013-07-12 15:38 UTC, Paul Howarth
Details
Example file (616 bytes, application/x-php)
2013-10-23 13:29 UTC, Jim Hayward
Details
screenshot with correct line comment highlighting (34.07 KB, image/png)
2013-10-25 19:43 UTC, Olivier Sessink
Details
8133 showing highlighting error (140.72 KB, image/png)
2013-10-27 14:36 UTC, Jim Hayward
Details
Terminal output (8.77 KB, text/plain)
2013-11-03 14:30 UTC, Jim Hayward
Details
incorrect shell highlighting (5.56 KB, text/plain)
2013-11-05 02:43 UTC, Jim Hayward
Details
incorrect shell highlighting 8136 (6.92 KB, text/plain)
2013-11-05 13:33 UTC, Jim Hayward
Details
correct shell highlighting 8136 (12.86 KB, text/plain)
2013-11-05 13:34 UTC, Jim Hayward
Details

Description Paul Howarth 2013-07-12 15:38:50 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.
Comment 1 falsetti 2013-08-24 14:06:02 UTC
*** Bug 705988 has been marked as a duplicate of this bug. ***
Comment 2 falsetti 2013-08-24 14:09:19 UTC
Thanks for reporting!
tested in last SVN the problem appears to be solved.
Comment 3 Jim Hayward 2013-08-25 17:00:37 UTC
I can confirm this bug is still present using current SVN on Fedora 19,
Comment 4 Olivier Sessink 2013-09-03 21:46:54 UTC
are you sure you used a new binary and new language files? I'm pretty sure I fixed this issue.
Comment 5 Pablo M. Rivas 2013-10-20 17:05:37 UTC
Confirmed in Ubuntu 13.10, and filled bug report [Bug 1242387] : https://bugs.launchpad.net/bugs/1242387
Comment 6 Olivier Sessink 2013-10-23 07:58:36 UTC
can anybody confirm if this bug is still reproducible in svn revision 8120? The example above works correctly, so it seems to be fixed.
Comment 7 Jim Hayward 2013-10-23 13:29:37 UTC
Created attachment 257918 [details]
Example file

File attached reproducing the problem with 8121 on Fedora 19.
Comment 8 Olivier Sessink 2013-10-25 19:43:14 UTC
Created attachment 258144 [details]
screenshot with correct line comment highlighting

example file shows correct on said revision.
Comment 9 Pablo M. Rivas 2013-10-25 19:46:40 UTC
The bug appeared on two pc's running recently upgraded ubuntu 13.10, but before upgrade (ubuntu 13.04) the highlighting was ok.
Comment 10 Jim Hayward 2013-10-27 14:36:02 UTC
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.
Comment 11 Arnold Nijboer 2013-10-29 21:17:53 UTC
*** Bug 711067 has been marked as a duplicate of this bug. ***
Comment 12 Olivier Sessink 2013-10-30 21:41:05 UTC
hmm how is this possible? it works on my computer and doesn't on yours.
Comment 13 Pablo M. Rivas 2013-10-30 22:09:08 UTC
(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.
Comment 14 Olivier Sessink 2013-10-31 19:54:59 UTC
it is a bluefish specific problem, which should have been fixed in the latest SVN revision, but apparently the bug is still present.
Comment 15 Arnold Nijboer 2013-11-01 08:29:38 UTC
(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
Comment 16 Jim Hayward 2013-11-01 13:03:58 UTC
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?
Comment 17 Olivier Sessink 2013-11-01 21:19:29 UTC
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)
Comment 18 Jim Hayward 2013-11-03 14:30:42 UTC
Created attachment 258851 [details]
Terminal output

Terminal output is attached
Comment 19 Olivier Sessink 2013-11-04 21:23:40 UTC
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....
Comment 20 Jim Hayward 2013-11-05 02:43:19 UTC
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.
Comment 21 Jim Hayward 2013-11-05 02:57:37 UTC
Simple three line test that I tried

# test comment
aaaa="$(dirname "$Env")"
RTadmin="$(dirname "$aaaa")"
Comment 22 Olivier Sessink 2013-11-05 10:28:53 UTC
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
Comment 23 Jim Hayward 2013-11-05 13:33:40 UTC
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.
Comment 24 Jim Hayward 2013-11-05 13:34:46 UTC
Created attachment 259014 [details]
correct shell highlighting 8136
Comment 25 Arnold Nijboer 2013-11-05 13:54:04 UTC
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.
Comment 26 Jim Hayward 2013-11-05 14:04:17 UTC
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.
Comment 27 Arnold Nijboer 2013-11-05 14:08:19 UTC
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.
Comment 28 Olivier Sessink 2013-11-05 15:15:15 UTC
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.
Comment 29 Jan Alexander Steffens (heftig) 2013-11-05 20:26:49 UTC
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?
Comment 30 Olivier Sessink 2013-11-05 20:34:09 UTC
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... :(
Comment 31 Jim Hayward 2013-11-06 03:56:13 UTC
(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.
Comment 32 Jim Hayward 2013-11-08 03:03:36 UTC
*** Bug 711644 has been marked as a duplicate of this bug. ***
Comment 33 Paul Howarth 2013-12-05 16:19:41 UTC
Works for me, and for the original reporter in Fedora bugzilla.
Comment 34 Daniel Leidert 2014-01-11 12:19:36 UTC
*** Bug 721922 has been marked as a duplicate of this bug. ***
Comment 35 mygoggie 2014-01-11 13:20:46 UTC
Downloaded v2.2.5b2 and built RPM. Installed on openSUSE 13.1 and the PHP highlighting is working now. Thanks!
Comment 36 mygoggie 2014-01-11 13:29:53 UTC
(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.
Comment 37 Jim Hayward 2014-01-25 15:37:03 UTC
*** Bug 722830 has been marked as a duplicate of this bug. ***
Comment 38 Fiable.biz 2014-07-31 21:45:46 UTC
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.
Comment 39 Olivier Sessink 2014-08-12 21:03:04 UTC
We cannot fix it in Mageia unless they want to backport this fix..