Syntax highlighting bug?


Hi guys,
I am not sure if this is a bug, but I found a weird behavior with the syntax highlight feature. The problem is that I use the softwrap and when it wraps the new line at a point where there is for example the quotation mark symbol, it stops highlighting the rest of the line.

I attached a screenshot of what I mean, as you can see, when the text is wrapped to a new line (softwrap), the highlighting is incorrect if the wrap is just at the point of the word end.


This looks like a long line, we have an open issue for syntax highlighting being broken on long lines here Does this bug happen for shorter lines as well? Does it happen if you start atom in safe mode atom --safe?


thanks for reply. No, this only occurs with long lines, but it is annoying because when you have for example longer texts where you need to use one line (otherwise the alignment in HTML can be messed up) and you insert some parts to it in PHP, then similar stuff occurs.


And regarding the bracket matching, there is also a problem in the syntax, it works but only if the brackets are on a different line.

If I have for example:
$current[‘avgT’] = convertT($row[‘avg(T)’]);
Then the round brackets are not matched, I used to use Notepad++, which highlighted all brackets and it is particularly useful when you have two brackets behind each other, for example:


In the above example, it can happen that you forget the second bracket after “arr” and in Notepad++, they are highlighted so I see that it is matching the first one and that I need to add one more. In Atom unfortunately, it only matches brackets if they are on different lines.

I just switched to Atom from Notepad++ and I love it, but these little things are slightly annoying.


These brackets match for me:

Check if you can reproduce the bracket matching behavior in safe mode atom --safe. It might be that a community package you have installed is causing this.


Yes you are right, safe mode works fine, so does that mean it is some package I installed additionally?


OK I found the issue, it is the “Zenburn” theme that I installed. It is the one I used in Notepad++ so Im quite used to this color scheme. When I switch to Atom One, it works fine. Do you have any ideas what I could do to make the bracket matching work in the theme?


So just disregard the bracket matching. The issue with the syntax highlighting however is a problem in general and it is not just this. Have a look at this screen. When I echo a number in PHP inside JS, it is not highlighted, only if it is in quotes (which is not what I want in this case). The firstWeekday must be a number in the JS and it is not higlighted as it should be


Yes, safe mode disables all installed community packages which helps narrow down the cause of the problem.

I would create an issue on the repository of the theme you have installed after checking if there is one already. You can easily access the correct repository to file an issue from the settings-view


Thanks, also have a look at the other problem with the syntax highlighter. I acutally found a few already, the syntax highlihgting in Notepad++ works much better I have to admit that.


I believe the problem of php not being highlighted correctly has been fixed in Atom 1.13.


Aha, ok, well the strange thing is that I have autoupdates turned on and when I manually click “Check for updates” I get:

“No update available. Version 1.12.6 is the latest version”


That is because 1.13 is currently only in beta.


Got it. OK thanks for the link, I will wait until it is released. It is obviously not a big deal, but it would be nice if this was fixed because it will make it much more clear when looking at the code. I can wait, the important thing is that it is being dealt with.

btw. I really love this editor. I used notepad++, which as I said, is also quite good, but the major issue I had with it is that I have Linux at home and Notepad++ only works on Windows. And I tried Sublime trial, but Atom is much better, only a tiny bit slower.


Regarding the question about long lines: Atom has a hard-coded limit of 100 tokens per line (a token is a marker that lets the editor know that a tag needs to be inserted for highlighting) for performance reasons. Once it hits that limit, it stops processing and moves to the next line.


That makes sense, but it would be useful if one could turn it off when necessary. When you are dealing with these longer HTML strings I would sacrifice speed and prefer having it highlighted


The open issue about this is here:


Well so far I have to say Im absolutely impressed by Atom in general and I will definitely keep on using it as my primary code editor. This however is really the only thing that is really annoying. I understand why it was limited, but there should be an option to disable this or increase the limit.

The problem is that for example, as you know, in HTML blank spaces matter so if for example I have some table cell which has a relatively long content, I cannot split it to several lines if I want that cell to have the text aligned in the middle. If you set text alignment to “center” and you put blank spaces after < br >, you will see that it will not be exactly in the middle, that space will shift it slightly, which does not look good. And sometimes, I even need to echo some one or two variables in that cell text and what I end up with is just one-colored long text with PHP, HTML etc.

Or if someone could help me find that piece of code where I could manually disable the 100 character limit.


would be nice if one could disable or change that limit. Is it at least possible manually?


Browsers completely ignore newlines and tabs. Spaces are rendered, and if you’re using spaces to indent your code, then you should probably just use tabs.

Or if someone could help me find that piece of code where I could manually disable the 100 character limit.

It’s a token limit, not a character limit. The limit is hard-coded and if you aren’t up for finding it, you probably also don’t want to have to build Atom from source every time an update comes out as well as taking the trouble to fix your own bugs or at least verify that any future problems you have aren’t associated with the change, because that’s what you’re going to do if you’re running a different set of software than everyone else.

Anyway, it’s here. Have at.