Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inheritance access specifier not colorized at linebreak #14

Closed
ember91 opened this issue Mar 8, 2019 · 5 comments
Closed

Inheritance access specifier not colorized at linebreak #14

ember91 opened this issue Mar 8, 2019 · 5 comments
Assignees
Labels
🐛 Bug Something isn't working

Comments

@ember91
Copy link

ember91 commented Mar 8, 2019

Describe the bug

  • OS and Version: Ubuntu 18.04.2 LTS
  • VS Code Version: 1.31.1
  • Better C++ Syntax Extension Version: 1.4.11
  • Other extensions you installed (and if the issue persists after disabling them): C/C++. The issue persists after disabling it.
  • A clear and concise description of what the bug is: When linebreaking after an inheritance colon, the access specifier, such as 'public', is not colorized.

To Reproduce

  1. Create a new file with extension '.cpp'.
  2. Input the code below in the newly created file. Note the linebreak after the colon.
class B
{};

class A : 
  public B
{};
  1. Try removing the linebreak, writing 'public B' on the same line as 'class A'. The keyword is suddenly colorized.

Expected behavior
The 'public' keyword should be colorized regardless if there is a linebreak or not.

Screenshots
screenshot from 2019-03-08 15-36-37

Additional context
This issue exists with default VS code highlighting as well.

@jeff-hykin
Copy link
Owner

jeff-hykin commented Mar 8, 2019

Just for reference (for other people) fixing this issue also would fix the issue posted here atom/language-c#245

I've got bad news though :/

TextMate grammars have basically two ways of matching things

  1. Regex match
  2. Range (start and end) match
  • Start must be a Regex match
  • End must be a Regex match

The caveat is, the Regex match for TextMate cannot match newlines. (This is something inherently limiting about the TextMate implementation.) If something contains newlines, say a class definition:

class A {
    // newline 
}

then you're supposed to use a Range.

Right now the range start is basically class { and the range end is }, but since there's no way to include newlines in the start, theres no straightforward way to match the class : \n*parents* { at the start. We could remove the class {, } range, but it is also used to style things like public:, and private: which are only allowed in class/struct definitions.

Now, their might be a clever way to get a make-shift solution and get around this which I'll try to work on, but the root problem is that the syntax highlighting is inherently limited. This is something a Tree Sitter would fix and this issue should additionally be logged on the VS Code repo.

Ideas for a hacky solution:

  • Have class A be the start, and } be the end, and then just guess-style for the first { and the inheritance
  • Have class be the start and have } be the end, then have a internal range that starts with lookBehindFor(class) and finds all the inherited classes and ends with {

@ember91
Copy link
Author

ember91 commented Mar 8, 2019

Thanks for the response! Perhaps waiting for tree sitter is the right way to go. It seems like it may appear in VS code in the future. I'll report the issue there as well, which may speed up the process.

@ember91
Copy link
Author

ember91 commented Mar 8, 2019

The issue has already been reported in VS code here, which moved here, as previously mentioned by Jeff.

@jeff-hykin
Copy link
Owner

Good news. I've been refactoring the code the last few days and I discovered a way to do it.

It turns out the legacy code is not actually using a range, they're instead just using a very long normal pattern matcher for only the beginning of the class.

It is still going to take a bit to implement the fix, but at least it's possible. 👍

@jeff-hykin jeff-hykin added 🐛 Bug Something isn't working and removed Nearly Impossible :( Things that likely need more than just Textmate matching to fix labels Mar 13, 2019
@jeff-hykin
Copy link
Owner

I published a fix this with version 1.6.1 and pushed it just now. I'm going to do more work on it since the whole class pattern/tagging needs to be updated, but for usage purposes it should at least be highlighted now!

icecream17 added a commit to icecream17/pulsar that referenced this issue Feb 2, 2023
incorporates:

atom/language-c#252
Note that this particular change was modified. `class public virtual : public virtual Example` is invalid I think, but I don't see a good way to prevent that because the detection must be moved into `patterns > include` because textmate is not multiline regex.
See also jeff-hykin/better-cpp-syntax#14
(In fact that whole repostory probably has some improvements)
I changed it to include the angle brackets because types can have those

atom/language-c#263
atom/language-c#311
atom/language-c#368

For tree-sitter, kinda fix the Discord reported issue
(In #support M1 Mac C++ Syntax highlighting)

Note that I syntax color only the last function name and not the namespace or colon. But that could easily be changed.

For future me, the relevant tree-sitter namespace identifier scopes are:
`call_expression > qualified_identifier > identifier` and
`function_declarator > qualified_identifier > identifier`

I don't know anything about template functions so I left that untouched. So this is probably an incomplete fix.

Finally, add the `static_assert` operator. It's technically a directive so it'll appear purple, not blue. Again this could easily be changed so don't hesitate about feedback, idk anything about c++
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 Bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants