-
Notifications
You must be signed in to change notification settings - Fork 12
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
Fix indentation logic to be context aware #2
Comments
I recently addressed this in the official Vim mustache syntax plugin: mustache/vim-mustache-handlebars@678cc34 Try switching to that, or adopting something similar here. |
This should be handled ember-template-lint, yeah? |
@NullVoxPopuli Indentation is commonly handled in language syntax plugins. @ohcibi This was recently fixed in the mustache/vim-mustache-handlebars#93 repo very cleverly by @AndrewRadev. No need for state logic! |
vim-mustache-handlebars doesn't have all the additional syntax that ember templates have, though. because ember-templates are not handlebars :-\ |
This is true, however, one of Mustache's maintainers @bruno- let me know in an email exchange last year that he is comfortable with putting Ember-specific syntax in there, as long as it doesn't break basic Mustache/Handlebars highlighting. |
@jsit I dont know how to proceed here to be honest. I'm neither a maintainer of vim-ember-hbs nor of vim-mustache handlebars. I dont know about the future of standalone handlebars/mustache either. If those are something that exist outside of ember and ember-hbs just extends on that syntax, I'd prefer to have the vim-ember-hbs-plugin specify vim-mustache-handlebars as a dependency and to move anything thats pure mustache into that plugin. If on the other hand the only application of mustache was actually ember-hbs, I'd rather prefer to have only one plugin. If both plugins continue to exist we should additionally ensure that the names of the highlight groups etc. do align such that e.g. custom colorschemes don't have to support two different plugins. @joukevandermaas whats your take on this? Fwiw I can help maintaining this (vim-ember-hbs) plugin if theres need for that. |
I created this one, because mustache has syntax that is not valid (ember) hbs, and (ember) hbs has syntax that is not valid mustache. My opinion is, they are different languages and there is little to no value in code-sharing of syntax files. However, for indentation I can see the value as the hbs rules really are kind of an extension of the mustache ones (as far as I can tell). Either way I'm happy to do anything that makes users of this plugin more productive. I'll take PRs that copy from the other plugin, or any kind of setup that enables code-sharing. @ohcibi as far as maintenance goes, there are very few prs, and I tend to review them somewhat quickly. However if you want to have commit access to make the process quicker I'm open to that. Finally as for this issue, the template linter actually does not like it, it prefers to put the closing braces on the next line: {{#multiline
mustache=with
block
}}
.
{{/multiline}} Maybe following that suggestion solves the problem also? |
@joukevandermaas the template linter had some issues with that when I found that issue back in the days. So this might be a valid workaround although the position of the closing braces is still somewhat in discussion although this one is about multilines in combination with Regarding both projects I agree that they should kept separated. I wasn't looking into the mustache only plugin because of said differences. Maybe it is still possible to find a common base plugin as besides those differences both languages are pretty similar. |
With the current indentation logic its kinda impossible to correctly indent the following:
as we cannot easily tell wether
block}}
actually ends a block-opener-mustache ({{#multiline
) vs a simple mustache ({{input
)). In the first case we need to keep the indent and in the last case it should de-dented.I'm thinking of some kind of state-logic that not only counts the indent's width but also it's context.
The text was updated successfully, but these errors were encountered: