C++: Comments not always highlighted correctly

[Friedrich2]

Expected behaviour

C++ comments with // should be ended by the next newline character. (Source: [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4640.pdf](a draft (page 23 / 37 of 1589, section 2.7)) Thus, pluma, should highlight all characters between the character sequence // (outside of strings!) and \n in the same colour.

Actual behaviour

pluma does not do this, if the comment contains a ">" sign (I think that it might have been a "<", but only one of the two characters). The coment seems to be ended by this character.

Steps to reproduce the behaviour

1. Make a new file "test.cpp" (filename ending is relevant)
2. Open it in pluma.
3. Input "#include // test < test" (without the quotes)

The first "test" word should erroneously have another colour than the second.

MATE general version

Unknown. It was the PC of a friend, with at least one ubuntu core update awaiting installation. Since it was not my PC, I am not able to test it for myself. A (rather short) naive testing seemed to show that the problem is independent of the previous #include<...> directive and of other characters in the comment section.

I did not test /* ... */ comments.

I hope that even these tiny pieces of information are sufficient to reproduce this error.

Package version

Unknown.

Linux Distribution

Link to downstream report of your Distribution

[sc0w]

It works fine here in pluma 1.20.2

[Friedrich2]

Could you please try it with #include<iostream> // fuers >> und << too? (My friend sent me this as mal-functioning. So probably, I mistook > for <.)

Many thanks in advance!

[lukefromdc]

I can confirm that the SECOND test example
#include // fuers >> und <<
Does in fact terminate the comment prematurely, after the >> character

[selectiveduplicate]

I cant also confirm this. It also happens with gedit though...

[lukefromdc]

Not good news, as this means gedit never got a commit to fix this we could backport

[selectiveduplicate]

Maybe this has got something to do with gtksourceview that handles the syntax highlighting?

[lukefromdc]

That could be and would mean it has to be fixed upstream. I cannot post bug reports against GNOME as have not been able to keep an account there, possibly due to highly modified/locked down browsers and no time to debug their web interface with it. @raveit65 , @monsta ?

[monsta]

Yes, highlighting is done by GtkSourceView, we can't fix it here.

[lukefromdc]

I think I just found the fix for this by accident while trying to build gedit: build Pluma against gtksourceview-4 instead of gtksourceview-3. All it takes is two lines changes in configure.ac, and I got this result:

EDIT: this works with current gtksourceview-3 as well, whatever fixed it was backported

[lukefromdc]

Unfortunately, using gtksourceview-4 breaks the external-tools plugin, giving these errors:

/usr/lib/python2.7/dist-packages/gi/module.py:171: Warning: cannot register existing type 'GtkSourceBuffer'
  g_type = info.get_g_type()
/usr/lib/python2.7/dist-packages/gi/module.py:171: Warning: cannot add private field to invalid (non-instantiatable) type '<invalid>'
  g_type = info.get_g_type()
/usr/lib/python2.7/dist-packages/gi/module.py:171: Warning: g_once_init_leave: assertion 'result != 0' failed
  g_type = info.get_g_type()
/usr/lib/python2.7/dist-packages/gi/module.py:205: Warning: g_type_get_qdata: assertion 'node != NULL' failed
  type_ = g_type.pytype
/usr/lib/python2.7/dist-packages/gi/module.py:219: Warning: g_type_get_qdata: assertion 'node != NULL' failed
  g_type.pytype = wrapper
/usr/lib/python2.7/dist-packages/gi/module.py:219: Warning: g_type_set_qdata: assertion 'node != NULL' failed
  g_type.pytype = wrapper
/usr/lib/x86_64-linux-gnu/pluma/plugins/externaltools/__init__.py:146: Warning: cannot register existing type 'GtkSourceLanguage'
  language = document.get_language()
/usr/lib/x86_64-linux-gnu/pluma/plugins/externaltools/__init__.py:146: Warning: cannot add private field to invalid (non-instantiatable) type '<invalid>'
  language = document.get_language()
/usr/lib/x86_64-linux-gnu/pluma/plugins/externaltools/__init__.py:146: Warning: g_once_init_leave: assertion 'result != 0' failed
  language = document.get_language()

So we need some work there before we can switch over to the currently maintained branch of GtkSourceView

[lukefromdc]

On still further testing, I found that whatever change had been made to gtksourceview-4 had been backported to gtksourceview-3 , so this issue is now FIXED at least on Debian Unstable. This is true whether or not gtksourceview-4 is even installed, so I can confirm GNOME devs have fixed the problem.

@Friedrich2 ? can you retest this and see if you are still having this problem? If not we can close this, if so your distro may not have caught up yet.

[monsta]

You need to write something like #include <iostream>, as in #381 (comment)... it's not fixed at least in GtkSourceView 3.24.9.

[lukefromdc]

OK, I just confirmed that the full
#include // fuers >> und <<
test case still does not work. Worst of all, this is true even if I force-build against gtksourceview 4