for a *.php file, syntax highlighting only starts after '<?php'

[oniwo]

Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Have you checked to make sure your issue does not already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

If a file is saved as a *.php file, the editor checks the code for syntax only after '<?php'.

This is not suitable for me on some files that are deliberately pieces that I assemble to make a whole during usage.

The editor was not working this way at version 1.110.2023110716

Pulsar version

1.118.0

Which OS does this happen on?

🐧 Red Hat based (Fedora, Alma, RockyLinux, CentOS Stream, etc.)

OS details

Linux fedora 6.8.11-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Mon May 27 14:53:33 UTC 2024 x86_64 GNU/Linux

Which CPU architecture are you running this on?

x86_64/AMD64

What steps are needed to reproduce this?

1. Have a file saved with the extension 'php' on the file system.
2. type multiple lines of any code in the file
3. insert the string '<?php' before any line
4. all lines that come after '<?php' have syntax highlighting including bracket matching while the ones that come before don't have

Additional Information:

No response

[savetheclocktower]

Try this just to help me troubleshoot:

• Go to Settings, then the Packages pane, then search for “grammar-selector” and click on its Settings button
• Uncheck “Hide Duplicate Grammars”
• Then, on a PHP file exhibiting the issue, click on the “PHP” text in the status bar and switch the grammar to “PHP (TextMate)”
• See if this fixes the issue

I'm curious what sort of input would exhibit this problem. Since 1.110, we've added a new Tree-sitter PHP grammar and made it the default, but the old TextMate-style grammar is also designed not to highlight any PHP until it encounters a <?php tag (or equivalent).

[oniwo]

You are right - designed not to highlight any PHP until it encounters a <?php tag (or equivalent). I have confirmed that even the 1.110.2023110716 does not highlight syntax for code that come before the <?php tag but does highlight code that come after - but not for all files it seems.

Actually my problem is the absence of bracket pair matching (not the highlighting) in a file that does not have the <?php tag. As I stated when I filed the issue , I am working with some part-files that have tall functions and if '{' are not highlighted, it is practically unworthy using the editor. This is what made me realise that the syntax highlights were also not there and would be there on lines that come after the <?php. With version 1.118.0, I have gone through the steps you prescribed using the file in the archive, markentry.php.zip and found out the following

• when I use the modern Tree-sitter PHP grammar, the the bracket pair recognition is not there, even when I insert the <?php tag at the top of the file. BUT if I save the file with the <?php tag at the top, close and open the file, then the syntax highlighting is still not there, the bracket matching is there but THAT IS THE END of typing anything in the file except the space character. Anything else results in the error message
  
  with the bug report
  bugReport.txt

• when I use the TextMate, without <?php at the top in the file, the bracket pair matching works just like I am used to it at version 1.110.2023110716. If I insert the <?php at the top, the syntax highlight comes to life! But I wish it would work regardless of the presence of the tag or not. This file is just a mid piece of a collection of pieces with <?php tag at the start of the file that comes first during the assembly.

So for me to work with comfort using version 1.118.0 for now, I have to make use of TextMate. I will test to see if the PHP parser does not mind multiple <?php in the same file. If so, I will insert the <?php tag at the top of each file to enjoy the benefit of syntax highlighting also.

[savetheclocktower]

So after looking at the file you've included, I understand exactly why neither grammar is able to parse this in the way that you expect.

1. The file starts in in the middle of a block of JavaScript. If the opening <script> were present, either grammar would be able to recognize the block as something that should be highlighted like JavaScript. But it's not.
2. Because the file has a .php extension, both grammars expect that any content outside of <?php/?> in the file will be HTML. That's why it highlights the JavaScript strings that contain HTML.
3. Inserting the <?php at the beginning of the file is wrong and will make PHP unhappy. It only appears to do the right thing in the TextMate grammar; in truth, inserting <?php tricks the grammar into thinking that the JavaScript is actually PHP! So it highlights the JavaScript as though it were PHP. The syntaxes are similar enough that you might not even notice the difference.
4. The Tree-sitter grammar doesn't like when you insert <?php at the top of the file because it's trying and failing to find a matching ?>. In PHP, it's legal to omit the matching ?> in some circumstances, but certainly not in this one, because it'll encounter another <?php on or around line 552, and that's a parsing error in PHP. I grant you that it shouldn't fail so catastrophically in this case, but this is honestly not a scenario I envisioned.

To summarize: PHP is permissive enough to know how to execute this file, but it's practically designed to be hard to highlight. I think both our grammars do quite well with this file, and would highlight it perfectly if you could restructure your code such that you could provide the opening <script> in this file instead of in some other file.

If you can find any other editor in common use that magically knows how to highlight everything in this file, I'd be interested in learning how. But aside from the Tree-sitter exception — which I'll capture separately, and which I appreciate you discovering — I'm afraid this isn't a bug.

[savetheclocktower]

Anyway, @oniwo, sounds like you should opt into the TextMate grammar for PHP; you can do that by visiting #876 and following the directions under the “I want to go back to the old highlighting!” heading. That will save you from manually having to change the parser each time you open one of these files.

[savetheclocktower]

OK, #1032 describes the Tree-sitter exception you encountered, and its fix is present in #1028. Closing this as not-a-bug.

[oniwo]

Thank you so much. I am glad now there is a fix for the Tree-sitter exception . Cant wait for version 1.119 to be available for download. Keep up this good work.