jawee / language-blade Goto Github PK

When i run auto-indent, Blade's control structures aren't indented correctly, probably because there aren't indentation rules in the grammar file.

    @if(count($client->addresses))
    <hr class="dashed">
    @foreach($client->addresses as $a)
    <div class="row">
        <div class="col-md-1">{{ trans('address.' . $a->type) }}</div>
        <div class="col-md-4">
            <address><strong>{{ $a->name }}</strong><br>
                {{ $a->address }}<br>
                {{ $a->zipcode }} {{ $a->city }}<br>
                {{ $a->country }}</address>
            </div>
        </div><!-- ./row -->
        @endforeach
        @endif

As you can see on the screenshot, the @endif does not get colored correctly.

Not a mayor issue, but worth mentioning.

Laratrust has some blade templates which might be worth including:

http://laratrust.readthedocs.io/en/3.2/usage/blade_templates.html

Hello, I'm using language-blade 0.26.2 with atom 1.10.2.

I have problem when I want to change the value of Tab Length to 2, it will always back to 4 automatically. How to fix it?

See laravel/framework@65589c8

GitHub now supports highlighting of Blade files (thanks to this package 🎉) however, it's unable to highlight the @end scopes due to inconsistent names.

github-linguist/linguist#3119 (comment)

As @Alhadis suggested, the repo needs to follow the guidelines on naming conventions.

Is it possible to highlight custom blade directives?

The @endsection was used in Laravel 3 and it was deprecated in Laravel 4
In Laravel 4, to end a section, you have to use @Stop

While in HTML file, I can write: .someclass , and with my cursor at the last position, when hitting TAB I am getting <div class="someclass">. Same goes for more complete structures like h1.page-title giving me <h1 class="page-title">, etc.

With Blade syntax selected this expansion doesn't work as expected, giving some strange results instead.

Blade grammar isn't automatically detected if file starts with:

`

However, if file starts with any other text, HTML elements, or Blade directives, then Blade grammar is properly detected for .blade.php files. This means that a master layout file doesn't show syntax highlighting on Blade directives, unless the user manually switches to Blade grammar mode.

Not sure if this is issue with language-blade, or how Atom itself handles grammar detection?

Hi,

Got forwarded from the GitHub linguist repository (github-linguist/linguist#3185), currently, GitHub does not highlight end calls, such as @endif or @endforeach.

Example:

@if ($errors->first())
    <div class="row">
        <div class="sixteen wide widescreen sixteen wide computer sixteen wide tablet sixteen wide mobile column">
            <div class="ui negative message">
                <div class="header">
                    There's been an error.
                </div>
                <ul class="list">
                    @foreach ($errors->all() as $error)
                        <li>{{ $error }}</li>
                    @endforeach
                </ul>
            </div>
        </div>
    </div>
@endif

UI Theme - One Dark, Syntax Theme - Base16 Tomorrow Dark.

When I put two or more sections in the same file the first section is ok but the others don't highlight properly and the first inner html tag have problems too.

I know this issue kinda came up in #1 and I mentioned that I had some issues with the language actually kicking in for blade files.

Here's what I've noticed:

• If I open a Blade file (e.g. xyz.blade.php) I've never opened it opens as a PHP file
• If I then switch the syntax to Blade manually it's fine
• If I then close the file and reopen it another time 9doesn't have to be immediately) it appears to remember it's a Blade file
• But still, other new unopened Blade files (e.g. abc.blade.php) open as PHP

Also (and pretty obviously), if I have previously switch a file's view mode to Blade so that it no re-opens in blade, I can then change it to PHP so that form now on it opens as PHP.

Is this just me or it is a bug? I know you at one point changed the fileTypes config setting to fix an issue with highlighting, but it still appears to be around for me. But maybe there's something I'm doing weird. So first of all it'd be nice to get confirmation, and then if no-one else has the same issue, see if there's a package I have that's sending if funny. Does Atom have any debugging mode/command to enable us to see the decision behind a syntax setting decision?

Using "Atom Dark" theme:

The reason why the first } is colored differently is because it's nearest class is source, which is/was required to get autocomplete to detect scope in situations where the cursor is right before the ending brace. With recent improvements to autocomplete, it needs to investigated whether we need the hack anymore or should we go with PHP-s solution where a workaround has been applied (https://github.com/atom/atom-dark-syntax/blob/master/index.less#L179) - that would change the color of the curly braces.

Blade has evolved quite a lot during the past year and the amount of downloads for this package has more than doubled during that time! Thank you to everyone who has upped the counter during that time 😃

While there are very few issues left to solve (or people just don't report them), I think we can do better.

1. The current grammar is rather short, around 100 lines, but it's undocumented, making it a little hard to maintain or understand what goes where when adding a new keyword. In the process I am planning to expand the compacted regular expressions into longer chunks for better readability and making it easier for others to add stuff.
2. Adding tests. But instead of just doing what core Atom language repositories do, I think we should be running our test fixtures against the blade compiler itself as well, that resides over at https://github.com/illuminate/view , if something changes there, it might be a good indication that we need to change something too. Also getting notified of new features would be a great feature for us so someone could implement those quickly.
3. Revamping the documentation of this repository - update README.md, add LICENSE.md, CONTRIBUTING.md and {ISSUE,PULL_REQUEST}_TEMPLATE.md. This should improve the quality of upcoming bug reports a great deal. For the license I am thinking of MIT license.
4. Snippets - while I personally don't write code using them, they work rather well for me as a reminder what one is supposed to write. So one could conclude that the snippets we have at the moment could be in a lot better shape than they are at the moment in order to write anything efficiently with them. @slayerfat, what do you think, can we work together to provide a single package (this one) for all of the Blade awesomeness?
5. Grammar scopes - we've had a lot of trouble with this for the past year. Typically the problem is that the scope names that are semantically correct might not look that pretty with different themes (not highlighted at all or is highlighted the same way as HTML tags etc...). I think we should find some outside help or at least devise a plan how to improve consistency between different themes (see what core or more popular packages do).
6. Atom issues. There are some which have lead me to use hacks. It would be great to document those as issues in other repositores and keep a reference to this repository.
   1. This grammar is 2300 lines long, and not 200, because first-mate doesn't properly support recursive grammar scopes. The workaround was to take PHP grammar, which injects into language-html, add our changes into it and keep it in sync with Atom releases.
   2. Because language-php grammar is a big mess that just works, nobody has taken their time to properly implement matching parentheses inside the grammar. Currently our grammar is limited to highlighting code such as @if (myfunc($myvar)) on a single line. If PHP grammar supported matching parentheses, we could adapt our grammar to multiple lines and this way handle very complex use cases.
   3. Some Atom component (probably first-mate again) doesn't support zero-width tokens. Because of that packages such as autocomplete in cases such as {{|}} where | is text cursor, cannot recognize that they are inside the PHP grammar scope and keep providing Blade's shortcuts. The hack to solve this is to mark the first closing } as part of PHP grammar scope, which I nicely covered up with some CSS so it would work with any theme.

In summary all of those things are rather small alone, but together they are still a lot of work. There are things from which others can benefit. I'll probably work on some things during Good Friday weekend (I am thinking of taking 1, 2 and 6). Others (except 3) might require more time, but I think we can find a reasonable solution in reasonable time.

Suggestions/thoughts are welcome.

cc @jawee

In language-blade/styles/language-blade.atom-text-editor.less:

Starting from Atom v1.13.0, the contents of atom-text-editor elements are no longer encapsulated within a shadow DOM boundary. This means you should stop using :host and ::shadow pseudo-selectors, and prepend all your syntax selectors with syntax--. To prevent breakage with existing style sheets, Atom will automatically upgrade the following selectors:

• .support.function.construct.end.blade .source.php => .syntax--support.syntax--function.syntax--construct.syntax--end.syntax--blade .syntax--source.syntax--php

Automatic translation of selectors will be removed in a few release cycles to minimize startup time. Please, make sure to upgrade the above selectors as soon as possible.

Can you support the new raw HTML output of Blade in Laravel 5, please?

{!! Form::open() !!}

You can read the Laravel 5 Templates doc for more information.

In language-blade\styles\language-blade.atom-text-editor.less:

Starting from Atom v1.13.0, the contents of atom-text-editor elements are no longer encapsulated within a shadow DOM boundary. This means you should stop using :host and ::shadow pseudo-selectors, and prepend all your syntax selectors with syntax--. To prevent breakage with existing style sheets, Atom will automatically upgrade the following selectors:

• .support.function.construct.end.blade .source.php => .syntax--support.syntax--function.syntax--construct.syntax--end.syntax--blade .syntax--source.syntax--php

Automatic translation of selectors will be removed in a few release cycles to minimize startup time. Please, make sure to upgrade the above selectors as soon as possible.

I'm gonna deal with it eventually, however I believe prepending all syntax classes with syntax-- is a bit dumb. If there is no other way around this, then I'll do the necessary changes.

I'm not able to leave TabLength as 2 for language blade which is the default while php has a tabLength of 4.

I would like to have blade with tabLength as 2 and php as 4?

I'm using atom 1.8.0

Thanks

Scout is a fork of Blade for the Themosis framework. Would it be possible to add support for this in the plugin?
http://framework.themosis.com/docs/scout/

I have both language-blade and atom-laravel packages installed. Your "section" trigger is outputting outdated @endsection directive, while it blocks the @Stop directive from atom-laravel package.

So far I noticed @component, @endcomponent, @slot and @endslot from changelog, but knowing Taylor, he sneaked in some other stuff.

This time he also managed to break nearly all the blade "compilers" into traits, which makes diffing 5.3->5.4 harder.

See that the following example would highlight with invalid.illegal scope.
Like it is done here:

{{--<?php echo $this->anchor; ?>--}}
{{-- @foreach($bla) --}}

Case 1:

<form name="bt_filter" method="get" action="{{--<?php echo $this->anchor; ?>--}}">
<form name="bt_filter" method="get" action="{{--@foreach($bla)--}}">

Case 2:

<script type="text/javascript">
  {{--
@foreach($bla)
<?php echo $this->anchor; ?>
  --}}
</script>

As you can see in the screenshot attached, the blade comments are not getting proper formatting while double slash comments work just fine.

I changed syntax and theme to no avail.

Thanks.

Possible use case

@ingramz (https://twitter.com/ingramz) 

Possibly a negative lookahead for //.*?\) could work, I'll look into it later.

Right now block directives are automatically indented, but the same should be done to echo/comment brackets such as {{, }}, {!!, !!}, {{{, }}}, {{-- and --}} because sometimes they can span across multiple lines.

Hi !

I found a bug with indent guides,

when the extension is enabled:

After disabling it:

There is a little space character playing with us at lines starts there :)

It would be awesome if this repository keep a changelog.

greetings, the new L5 blade sintax has changed from:

{{{ function($var) }}}

to

{!! function($var) !!}

and other minor changes.

im a complete noob on using cson, however if i can help ill make a pull request with a solution, but anyone with experience can help with this issue.

screenshot:

[Enter steps to reproduce below:]

1. ...
2. ...

Atom Version: 1.6.1
System: Ubuntu 14.04.4
Thrown From: language-blade package, v0.24.1

Stack Trace

Failed to load a language-blade package grammar

At Grammar missing required scopeName property: /home/damian/.atom/packages/language-blade/grammars/blade.cson in /home/damian/.atom/packages/language-blade/grammars/blade.cson

Error: Grammar missing required scopeName property: /home/damian/.atom/packages/language-blade/grammars/blade.cson
    at /usr/share/atom/resources/app.asar/node_modules/first-mate/lib/grammar-registry.js:122:64
    at /usr/share/atom/resources/app.asar/node_modules/season/lib/cson.js:180:53
    at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:380:3)
  at /home/damian/.atom/packages/language-blade/grammars/blade.cson:1:1

Commands

Config

{
  "core": {
    "disabledPackages": [
      "atom-beautify"
    ],
    "packagesWithKeymapsDisabled": [
      "atom-beautify",
      "sublime-block-comment"
    ]
  }
}

Installed Packages

# User
Remote-FTP, v0.7.20
color-picker, v2.1.1
css-specificity, v0.2.2
emmet, v2.4.3
jquery-snippets, v11.0.0
language-blade, v0.24.1
linter, v1.11.4
linter-bootlint, v1.0.2
linter-csslint, v1.3.2
linter-htmlhint, v1.1.1
linter-jshint, v2.0.3
linter-php, v1.2.0
local-history, v3.2.3
minimap, v4.21.0
project-manager, v2.9.0
project-viewer, v0.2.31
terminal-plus, v0.14.5

# Dev
No dev packages

When I use ctrl+/ to toggle comment I get HTML comment which is , so can I use short cut to comment in blade file as {{-- --}}> ?

Thank you very much.

brilliant work

PHP tags take precedence over comments.

{{--<?php echo $this->anchor; ?>--}}

Gets highlighted in some themes, but probably not in an intended way.

<form name="bt_filter" method="get" action="{{--<?php echo $this->anchor; ?>--}}">

I work with Laravel and when i open a blade file with your package this is the result:

Fix?
Thx

The {!! ... !!} raw output tags don't seem to work the same way as the {{ ... }} when invoked. Not quite sure why, still investigating.

As the title says, syntax highlighting goes awry if using a @​parent tag in a Blade template:

The highlighting is incorrect when we use blade output as part of an attribute without putting it in quotes.

Example:
<input class="form-control" type="text" name="client_name" value={!! json_encode(e($client->name)) !!}>

Screenshot:

An option to disable blade comments would be awesome.

For now i have to remove the below from language-blade.cson

'.text.html.php.blade':
  'editor':
    'commentStart': '{{-- '
    'commentEnd': ' --}}'

See the screenshot below:

I think the foreach breaks it

By default "use blade comments" setting is enabled, which will automatically add

".blade.html.php.text":
  editor:
    commentEnd: " --}}"
    commentStart: "{{-- "

to the user's config file. While this is not a great crime, because it is namespaced (scoped), it would be better if we could achieve the same thing without having to write into the config file.

Here's an example:

Keeps jumping back to 4.

Previously, using this package to insert Blade directives added directives without any spaces (i.e. @foreach($foo as $bar), @if($foo) etc. Now, directives contain spaces between the directive name and the opening parenthesis, i.e. @foreach ($foo as $bar), @if ($foo) etc. This means I know have code that is non-uniform.

What was the reason for this change? I preferred the non-space version for consistency, as you write @section('section.name') not @section ('section.name') and @include('path.to.include') not @include ('path.to.include').

Hi, the reason why I looked for a package to highlight blade code was precisely because of the commented code. I'd like to have it all greyed out as on other languages.

However language-blade is only showing the code greyed out if there are no colors inside:

Is this something that can be easily fixed?

Thanks in advance, cheers! :)

Fresh out of the oven: http://laravel.com/docs/5.1/authorization#within-blade-templates

What is the license for this project?