language-blade icon indicating copy to clipboard operation
language-blade copied to clipboard
verified publisher icon jawee

Incorrect syntax highlighting of `{{ }}` statements

Open FeBe95 opened this issue 11 months ago • 3 comments

There is an issue when using the {{ }} statement in blade files. The first closing curly bracket is not highlighted correctly when the statement is used inside of HTML attribute values.

Example:

<img src="{{ $foo }}">        <!-- incorrect -->

<span>foo {{ $bar }}</span>   <!-- correct -->

[!Note] I came across this issue while browsing some blade files in our GitHub repository. GitHub is using your package for highlighting blade files, see: https://github.com/github-linguist/linguist/blob/main/vendor/README.md.

FeBe95 avatar Jan 07 '25 13:01 FeBe95

Hi! Thank you for the issue report.

I can explain what the differently highlighted curly bracket was used for. In Atom when someone typed {{}} and placed their cursor in the middle, the parser did not understand that inside it may contain PHP code, so none of the autocomplete options appeared. When the contents between curly brackets had length greater than 0, everything worked fine.

To remedy this, I used a trick that I saw in some other TextMate grammar, where the first character of the closing token was scoped the same as the contents would have been (source.php). To fix any potential visual inconsistencies, we added some custom styles to reset the styles for that token.

The case you have provided was likely never tested against GitHub Linguist and it's fair to assume that they should not be supporting the Atom-specific CSS overrides to accommodate the same hack, which leads to possible options to solve this particular use case:

  1. Erase the hack from the codebase - Atom has been EOL for a while now and it's reasonable to assume that anyone who is interested in syntax highlighting for Blade is either using a fork of this repository or a different editor/package.
  2. Create a separate grammar for Linguist which does not include editor-specific workarounds. This should be only done if there is someone that still depends on this repository for some Atom fork.
  3. Have Linguist switch to a different repository for the TextMate grammar. My day-to-day work unfortunately does not currently involve working with PHP and therefore I am not too invested in anything related the language. The most straightforward way to go about this would be to look at whatever is currently the de-facto Visual Studio Code grammar for Blade and politely pass the maintenance on them. This way Linguist would also be benefiting from new Blade constructs "for free" if there are any.

I'll try researching these options sometime soon, but in meantime I welcome any thoughts or feedback regarding the direction we should be taking.

Ingramz avatar Jan 07 '25 13:01 Ingramz

Hi, thanks for the quick and detailed response. I'm always curious to know why things behave in a specific way, and your explanation makes a lot of sense to me!

Regarding your three options I have the following thoughts:

  1. I remember reading somewhere that Atom was being retired some months/years ago, but I've never really used Atom myself. I also don't know how the Atom ecosystem works as of today, and if changing this repository might break Blade support for existing Atom installations. If this is the case, then I would argue against removing all Atom-related hacks from this repo, because there might be still some people using Atom as their main editor.
  2. I agree. This would be a good alternative, but only if people depend on the hacks to be present in this repo.
  3. I've done some research for alternative solutions, see below.

Alternative solutions

AFAIK GitHub Linguist supports various types of syntax definitions. The main types being Text Mate (.tmLanguage) and tree-sitter definitions. There are other file formats, such as the newer .sublime-syntax, but I am unsure whether Linguist is able to use those. Sublime Text was primarily using Text Mate syntax definitions, but they switched to this newer format in the recent years.

I've found some discussions about Sublime's new syntax files being (un-)supported by Linguist, but I cannot exactly tell if the syntax is supported as of today.

Note: There might also be tools available to convert one file format to the other.

Regardless, here are some relevant repositories I have found:

There are also some other Laravel Blade VS Code extensions available with a couple of 100k downloads, but those seem to be less maintained or even completely unmaintained. Some of them are even converted from the definitions in your repository (laravel-blade, Laravel Blade).

Conclusion

The most straightforward solution would be to remove everything related to Atom from this repository and wait for GitHub Linguist to catch up. If we don't want to go with this option, we could request to change the Linguist Blade grammar to any of the packages above. I'd probably go with Medalink/laravel-blade then, if .sublime-syntax files are supported by Linguist, else with EmranMR/tree-sitter-blade.

Note: The people contributing to Linguist are usually pretty quick when it comes to responding and deciding on such topics. I just saw such a replacement being done for the .vue syntax, happening all within a few weeks (see: Replace Vue Grammar by yuichkun · Pull Request #7086 · github-linguist/linguist).

FeBe95 avatar Jan 07 '25 16:01 FeBe95

Apparently Pulsar, the community-driven fork of Atom hosts this package, so I am a bit reluctant to remove Atom-specific hacks in case it inevitably breaks someones workflow.

All your mentioned alternatives are good and have their merits. The first one, onecentlin/laravel-blade-snippets-vscode, actually being a fork of the grammar from this repository. If that grammar works in GitHub Linguist, I think it would be the most straightforward replacement. The high download count probably also means there are more people eager to add missing directives or keep the grammar in general up to date. The only drawback using this grammar is that it employs the same workaround as us, where we include the TextMate version of the PHP grammar inside Blade grammar as historically TextMate has only supported one level of injections between parent-child. This means that it is unlikely to receive any new PHP syntax, as TextMate grammars for PHP generally have gone unmaintained and most of the work is being done on the tree-sitter-php grammar instead.

Unfortunately I cannot find the Lightshow app anymore to test the highlighting of this grammar in order to compare it to ours. Lightshow was a handy tool when previewing TextMate grammars for use with GitHub Linguist. When previewing it in VSC, I found the brackets to be colored differently depending on context, but I think the GitHub's theme should have both the same color in both contexts.

Image

.sublime-syntax seems to be currently unsupported by Linguist, other than highlighting such source files as YAML. Sublime's reimagination of the TextMate grammar system with the stack-based scopes is actually very impressive and a big upgrade over its predecessor, but I believe it's still rather proprietary and only supported in Sublime Text.

tree-sitter-blade project looks exciting, hopefully someone will also make it available via VS Code. Unfortunately it seems that tree-sitter grammars aren't accepted from external contributors into GitHub Linguist, likely due to some SBOM/security concerns, so I don't see GitHub adopting it anytime soon.

In conclusion I think only the onecentlin/laravel-blade-snippets-vscode might fit the criteria when it comes to be accepted by Linguist. While conceptually it should be an evolution of this repository, I cannot vouch for the quality of the modifications made after forking, that being said, I do not expect that grammar to be a downgrade in any way to what we currently have here either.

So feel free to propose the repository change to Linguist via a pull request. From my past experience I can confirm that they work fast over at Linguist. If you need any help, do not hesitate to reach out to us here.

Ingramz avatar Jan 19 '25 02:01 Ingramz

the multi-coloured brackets is cause of the coloured bracket highlighting feature should add {{}} to the language brackets

theres https://novalightshow.netlify.app/ instead however it uses VSCode's TextMate engine so it doesnt have all of GitHub's bugs and shortfalls

here's my VSCode extension to help with authoring TextMate grammars https://marketplace.visualstudio.com/items?itemName=RedCMD.tmlanguage-syntax-highlighter

RedCMD avatar Aug 15 '25 05:08 RedCMD