-
Notifications
You must be signed in to change notification settings - Fork 33
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
Whitespace control #29
Comments
Yes, some kind of whitespace removal would be nice. But as some whitespace is sometimes needed, there need to be a good syntax to chose if whitespace should be kept or removed. |
Given a code block, there are basically four positions where there may or may not exist whitespace, and in a conditional, two of them may exist in two variants:
I think it is fairly unsurprising to amend the curly brackets (maybe with a dot or dash) to remove whitespace at start or end of a block, but it might be more surprising if something inside the block affects what happens before or after the block. Especially for a conditional block, where the if and else blocks may contain different whitespace hints. An example where whitespace in the block should be removed might look like this:
Would this be good? |
It looks odd to me, since How about: @some_whitespace_be_gone_keyword {
@if something { as usual }
} that removes: not here
@some_whitespace_be_gone_keyword { here
here @if something { here too } and here
} not here |
If we want some keyword to switch between differernt whitespace-handling modes, I think I want three modes to exist:
The only behaviour currently implemented is As-is, which is rarely whats wanted, but in the cases it is wanted it tends to be important. Compact is what I think should probably be the default (as long as as-is can be selected), and removed sometimes makes it possible to format the template code nicely without introducing "accidental" whitespace. I was rather sceptical to the "mode-switching" keyword you suggested, @kornelski , but after giving it some though from time to time I think it is probably a good idea. Having the possibility to switch between three modes also makes it possible to enable whitespace for blocks inside a block where it is disabled, like so:
|
Yes, that would work. I especially like the compact mode. |
As suggested in #29. A keyword `@whitespace` can be used to switch whitespace handling between the tree modes `as-is`, `compact`, and `removed`. - [x] Implment the functionality. Set default mode to `compact` and update tests. - [ ] Decide on the exact syntax; should some keyword change? Should `@ws` be allowed as an alias for `@whitespace`? Should the `removed` alternative be called `trim`? Or some other word change? - [ ] Add documentation and more tests / examples. - [ ] Anything else?
As suggested in #29. A keyword `@whitespace` can be used to switch whitespace handling between the tree modes `as-is`, `compact`, and `removed`. - [x] Implment the functionality. Set default mode to `compact` and update tests. - [ ] Decide on the exact syntax; should some keyword change? Should `@ws` be allowed as an alias for `@whitespace`? Should the `removed` alternative be called `trim`? Or some other word change? - [ ] Add documentation and more tests / examples. - [ ] Anything else?
I have a couple of places in HTML where I want to prevent any extra whitespace in the generated output:
Currently I'm just writing templates without spaces in them, but this isn't very convenient, since it requires use of long lines, and careful avoidance of any spaces.
So ideally I'd like some kind of block/directive that allows me to write template source with line breaks and indentation as usual, but remove that whitespace from the output.
I'm not sure what the syntax for it should look like, but generally template languages have blocks that either ignore all whitespace around elements, or trim whitespace at beginning and end of every line.
The text was updated successfully, but these errors were encountered: