Lucee smart whitespace management

Should Lucee really remove whitespace in form field values, if this setting is active?
“Smart whitespace management - every whitespace character that follows a whitespace is removed, but whitespace inside the tags: ,

 and  is kept”

One of our customers reported a bug – he had problems to upload files with multiple spaces into our CMS.
The reason was this setting – the form value for this file e.g. “test spaces.jpg”, was stripped to “test spaces.jpg”.

-Harry

We was discussing in the past to remove this feature completely in favor of
the gzip compression.
The current implementation is very simple but also very performant, adding
a smarter implementation has 3 downsides.

  1. Slows down performance
  2. it will never cover all kind of code, even the smartest implementation
    cannot cover every possible situation.
  3. it does not work when you use cfflush

So we need to ask yourself, why we are using this “feature” in the first
place, to reduce the band which necessary, to improve the parsing for the
client?
To reduce the band which, gzip compression is the better choice. the price
to reduce the work for the client is paid by the server, so not really a
good deal.

So in my opinion we should consider the following.

  1. remove the feature from the admin
  2. add a warning that it will not work in any case and people should
    consider to use gzip instead

I’m in favor of option #2

MichaOn Wed, Jul 1, 2015 at 4:21 PM, Harry Klein <@Harry_Klein> wrote:

Should Lucee really remove whitespace in form field values, if this
setting is active?

“Smart whitespace management - every whitespace character that follows a
whitespace is removed, but whitespace inside the tags: ,

 and

is kept” One of our customers reported a bug – he had problems to upload files with multiple spaces into our CMS. The reason was this setting – the form value for this file e.g. “test spaces.jpg”, was stripped to “test spaces.jpg”. -Harry -- You received this message because you are subscribed to the Google Groups "Lucee" group. To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com. To post to this group, send email to lucee@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/F5A941E045A6FE4288ABB2E3D797146FA73B8246%40SRV-DC1.contens.local . For more options, visit https://groups.google.com/d/optout.

p.s.

gzip should be used in addition to whitespace management – the two
features complement each other and are not mutually exclusive.

if you have to choose only one then I’d say go with gzip, but using both
together is a much better solution.

having said that, when I front Lucee with a web server I enable gzip on
the web server level, to account for javascript files, css files, etc.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/On 7/3/2015 8:39 AM, Igal @ Lucee.org wrote:

a few points:

I think that it’s very important to reduce the whitespace to a
minimum, and gzip is not an altertnative – you just have to compress
much more whitespace which could end up less performant.

I completely agree with Jean – I many times view-source. the fact
that there are other tools nowadays does not make that feature
obsolete. anyone who relies solely on the newer tools can face many
issues because those smart tools automatically fix some errors, so if
you try to find an unclosed element for example – good luck – the
developer tools will add the closing element for you in that view.
the only way to find it is by viewing the html source.

the original whitespace management had a major issue where it removed
whitespace everywhere, including textareas, which made it impossible
to use with forms, or to show code snippets. we added the so-called
“smart whitespace management” to resolve this issue.

solutions:

  1. we can add to the ignored tags in addition to the ,
, and  (actually instead of  since it should
be wrapped in a  anyway).

2) you can easily disable the whitespace management feature in the admin.

3) you can wrap your input/text field with , but if you expect
multiple whitespaces then IMO you should use a textarea instead of
input.  if you don't mind the validity of your html output, you can
just put an open  above your first input field and keep it open
-- in most cases nothing bad will happen from that.


Igal Sapir
Lucee Core Developer
Lucee.org 

On 7/3/2015 5:47 AM, Jean Moniatte wrote:
> You are right Adam, but regardless of the tool you choose to use to
> inspect the source, I still think that the source is better without
> the whitespaces.
>
> And I am not sure that it is the job of components or templates to
> make sure that they do not product whitespaces.
>
> Hopefully whitespace management will remain an option.
>
> Thanks,
> Jean
>
>
> On Fri, Jul 3, 2015 at 10:20 AM, Adam Cameron <@Adam_Cameron > wrote:
>
>
>
>     On Thursday, 2 July 2015 22:01:43 UTC+1, jmoniatte wrote:
>
>         And in all honestly, nothing beats in speed the "View
>         selection source" option in FF :
>
>         Inline image 1
>
>         Fancy or not, it works faster than looking at the DOM when
>         you need to know the markup of a specific portion of the page.
>
>
>     That very example mostly defeats your point though. You don't
>     need to fish around in the mark-up, you just right-click and it
>     takes you there. So it doesn't matter about bled-through whitespace.
>
>     And as an aside, I really struggle to accept you think going
>     "view source" there is better than using the option immediately
>     below: "inspect element".
>
>     All this more demonstrates to me that the whitespace "issue" is
>     more an issue for ppl who use a fairly out-of-date & subpar way
>     of going about things.
>
>     TBH, I think perhaps leaving the functionality in and just
>     documenting it as "not a very good way of dealing with the
>     perceived problem", but I also think that if one is actually
>     perceiving the problem, then one probably needs to rethink stuff
>     somewhat, as per Peter's observation.
>
>     -- 
>     Adam
>     -- 
>     You received this message because you are subscribed to the
>     Google Groups "Lucee" group.
>     To unsubscribe from this group and stop receiving emails from it,
>     send an email to lucee+unsubscribe@googlegroups.com
>     .
>     To post to this group, send email to lucee@googlegroups.com
>     .
>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/lucee/db876184-ca04-4f66-9254-48aff21c813d%40googlegroups.com
>     .
>
>
>     For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Lucee" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to lucee+unsubscribe@googlegroups.com
> .
> To post to this group, send email to lucee@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/lucee/CAG-7QUtxqOaQBnSCcsGNBHkWdvD5VnCVn5VtKL4v-G-51KKq4g%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.

You are right Adam, but regardless of the tool you choose to use to inspect
the source, I still think that the source is better without the whitespaces.

And I am not sure that it is the job of components or templates to make
sure that they do not product whitespaces.

Hopefully whitespace management will remain an option.

Thanks,
JeanOn Fri, Jul 3, 2015 at 10:20 AM, Adam Cameron <@Adam_Cameron> wrote:

On Thursday, 2 July 2015 22:01:43 UTC+1, jmoniatte wrote:

And in all honestly, nothing beats in speed the “View selection source”
option in FF :

[image: Inline image 1]

Fancy or not, it works faster than looking at the DOM when you need to
know the markup of a specific portion of the page.

That very example mostly defeats your point though. You don’t need to fish
around in the mark-up, you just right-click and it takes you there. So it
doesn’t matter about bled-through whitespace.

And as an aside, I really struggle to accept you think going “view source”
there is better than using the option immediately below: “inspect element”.

All this more demonstrates to me that the whitespace “issue” is more an
issue for ppl who use a fairly out-of-date & subpar way of going about
things.

TBH, I think perhaps leaving the functionality in and just documenting it
as “not a very good way of dealing with the perceived problem”, but I also
think that if one is actually perceiving the problem, then one probably
needs to rethink stuff somewhat, as per Peter’s observation.


Adam


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/db876184-ca04-4f66-9254-48aff21c813d%40googlegroups.com
https://groups.google.com/d/msgid/lucee/db876184-ca04-4f66-9254-48aff21c813d%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

a few points:

I think that it’s very important to reduce the whitespace to a minimum,
and gzip is not an altertnative – you just have to compress much more
whitespace which could end up less performant.

I completely agree with Jean – I many times view-source. the fact that
there are other tools nowadays does not make that feature obsolete.
anyone who relies solely on the newer tools can face many issues because
those smart tools automatically fix some errors, so if you try to find
an unclosed element for example – good luck – the developer tools will
add the closing element for you in that view. the only way to find it
is by viewing the html source.

the original whitespace management had a major issue where it removed
whitespace everywhere, including textareas, which made it impossible to
use with forms, or to show code snippets. we added the so-called “smart
whitespace management” to resolve this issue.

solutions:

  1. we can add to the ignored tags in addition to the ,
, and  (actually instead of  since it should be
wrapped in a  anyway).

2) you can easily disable the whitespace management feature in the admin.

3) you can wrap your input/text field with , but if you expect
multiple whitespaces then IMO you should use a textarea instead of
input.  if you don't mind the validity of your html output, you can just
put an open  above your first input field and keep it open -- in
most cases nothing bad will happen from that.


Igal Sapir
Lucee Core Developer
Lucee.org On 7/3/2015 5:47 AM, Jean Moniatte wrote:
> You are right Adam, but regardless of the tool you choose to use to
> inspect the source, I still think that the source is better without
> the whitespaces.
>
> And I am not sure that it is the job of components or templates to
> make sure that they do not product whitespaces.
>
> Hopefully whitespace management will remain an option.
>
> Thanks,
> Jean
>
>
> On Fri, Jul 3, 2015 at 10:20 AM, Adam Cameron <@Adam_Cameron > wrote:
>
>
>
>     On Thursday, 2 July 2015 22:01:43 UTC+1, jmoniatte wrote:
>
>         And in all honestly, nothing beats in speed the "View
>         selection source" option in FF :
>
>         Inline image 1
>
>         Fancy or not, it works faster than looking at the DOM when you
>         need to know the markup of a specific portion of the page.
>
>
>     That very example mostly defeats your point though. You don't need
>     to fish around in the mark-up, you just right-click and it takes
>     you there. So it doesn't matter about bled-through whitespace.
>
>     And as an aside, I really struggle to accept you think going "view
>     source" there is better than using the option immediately below:
>     "inspect element".
>
>     All this more demonstrates to me that the whitespace "issue" is
>     more an issue for ppl who use a fairly out-of-date & subpar way of
>     going about things.
>
>     TBH, I think perhaps leaving the functionality in and just
>     documenting it as "not a very good way of dealing with the
>     perceived problem", but I also think that if one is actually
>     perceiving the problem, then one probably needs to rethink stuff
>     somewhat, as per Peter's observation.
>
>     -- 
>     Adam
>     -- 
>     You received this message because you are subscribed to the Google
>     Groups "Lucee" group.
>     To unsubscribe from this group and stop receiving emails from it,
>     send an email to lucee+unsubscribe@googlegroups.com
>     .
>     To post to this group, send email to lucee@googlegroups.com
>     .
>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/lucee/db876184-ca04-4f66-9254-48aff21c813d%40googlegroups.com
>     .
>
>
>     For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Lucee" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to lucee+unsubscribe@googlegroups.com
> .
> To post to this group, send email to lucee@googlegroups.com
> .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/lucee/CAG-7QUtxqOaQBnSCcsGNBHkWdvD5VnCVn5VtKL4v-G-51KKq4g%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.

And in all honestly, nothing beats in speed the “View selection source”
option in FF :

[image: Inline image 1]

Fancy or not, it works faster than looking at the DOM when you need to
know the markup of a specific portion of the page.

That very example mostly defeats your point though. You don’t need to fish
around in the mark-up, you just right-click and it takes you there. So it
doesn’t matter about bled-through whitespace.

And as an aside, I really struggle to accept you think going “view source”
there is better than using the option immediately below: “inspect element”.

All this more demonstrates to me that the whitespace “issue” is more an
issue for ppl who use a fairly out-of-date & subpar way of going about
things.

TBH, I think perhaps leaving the functionality in and just documenting it
as “not a very good way of dealing with the perceived problem”, but I also
think that if one is actually perceiving the problem, then one probably
needs to rethink stuff somewhat, as per Peter’s observation.On Thursday, 2 July 2015 22:01:43 UTC+1, jmoniatte wrote:


Adam

gzip is also a problem for https websites due to the BREACH vulnerability
(http://breachattack.com/). While it is ok to enable gzip for static
resources, one shouldn’t do so for dynamic output with sensitive data in it.–
krushik

пятница, 3 июля 2015 г., 18:48:19 UTC+3 пользователь Igal написал:

p.s.

gzip should be used in addition to whitespace management – the two
features complement each other and are not mutually exclusive.

if you have to choose only one then I’d say go with gzip, but using both
together is a much better solution.

having said that, when I front Lucee with a web server I enable gzip on
the web server level, to account for javascript files, css files, etc.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/
On 7/3/2015 8:39 AM, Igal @ Lucee.org wrote:

a few points:

I think that it’s very important to reduce the whitespace to a minimum,
and gzip is not an altertnative – you just have to compress much more
whitespace which could end up less performant.

I completely agree with Jean – I many times view-source. the fact that
there are other tools nowadays does not make that feature obsolete. anyone
who relies solely on the newer tools can face many issues because those
smart tools automatically fix some errors, so if you try to find an
unclosed element for example – good luck – the developer tools will add
the closing element for you in that view. the only way to find it is by
viewing the html source.

the original whitespace management had a major issue where it removed
whitespace everywhere, including textareas, which made it impossible to use
with forms, or to show code snippets. we added the so-called “smart
whitespace management” to resolve this issue.

solutions:

  1. we can add to the ignored tags in addition to the ,

    ,
    and (actually instead of since it should be wrapped
    in a anyway).

  2. you can easily disable the whitespace management feature in the admin.

  3. you can wrap your input/text field with , but if you expect
    multiple whitespaces then IMO you should use a textarea instead of input.
    if you don’t mind the validity of your html output, you can just put an
    open above your first input field and keep it open – in most cases
    nothing bad will happen from that.

Igal Sapir
Lucee Core Developer
Lucee.org http://lucee.org/
On 7/3/2015 5:47 AM, Jean Moniatte wrote:

You are right Adam, but regardless of the tool you choose to use to
inspect the source, I still think that the source is better without the
whitespaces.

And I am not sure that it is the job of components or templates to make
sure that they do not product whitespaces.

Hopefully whitespace management will remain an option.

Thanks,
Jean

On Fri, Jul 3, 2015 at 10:20 AM, Adam Cameron <camero...@gmail.com <javascript:>> wrote:

On Thursday, 2 July 2015 22:01:43 UTC+1, jmoniatte wrote:

And in all honestly, nothing beats in speed the “View selection source”
option in FF :

[image: Inline image 1]

Fancy or not, it works faster than looking at the DOM when you need to
know the markup of a specific portion of the page.

That very example mostly defeats your point though. You don’t need to
fish around in the mark-up, you just right-click and it takes you there. So
it doesn’t matter about bled-through whitespace.

And as an aside, I really struggle to accept you think going “view
source” there is better than using the option immediately below: “inspect
element”.

All this more demonstrates to me that the whitespace “issue” is more an
issue for ppl who use a fairly out-of-date & subpar way of going about
things.

TBH, I think perhaps leaving the functionality in and just documenting
it as “not a very good way of dealing with the perceived problem”, but I
also think that if one is actually perceiving the problem, then one
probably needs to rethink stuff somewhat, as per Peter’s observation.


Adam

You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/db876184-ca04-4f66-9254-48aff21c813d%40googlegroups.com
https://groups.google.com/d/msgid/lucee/db876184-ca04-4f66-9254-48aff21c813d%40googlegroups.com?utm_medium=email&utm_source=footer.

For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+un...@googlegroups.com <javascript:>.
To post to this group, send email to lu...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CAG-7QUtxqOaQBnSCcsGNBHkWdvD5VnCVn5VtKL4v-G-51KKq4g%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CAG-7QUtxqOaQBnSCcsGNBHkWdvD5VnCVn5VtKL4v-G-51KKq4g%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

Hi Micha,

well, this setting caused several problems in the past:

  •      JSON Data inside Javascript CDATA tags was changed
    
  •      Multiple Spaces in Richtext Form Values were removed (form post)
    
  •      Multiple Spaces in Filename Form Values were removed (form post)
    

I am also in favor of option #2, and would suggest to add a warning in the admin!

-HarryVon: lucee@googlegroups.com [mailto:lucee@googlegroups.com] Im Auftrag von Michael Offner
Gesendet: Donnerstag, 2. Juli 2015 08:48
An: lucee
Betreff: Re: [Lucee] Lucee smart whitespace management

We was discussing in the past to remove this feature completely in favor of the gzip compression.
The current implementation is very simple but also very performant, adding a smarter implementation has 3 downsides.

  1. Slows down performance
  2. it will never cover all kind of code, even the smartest implementation cannot cover every possible situation.
  3. it does not work when you use cfflush

So we need to ask yourself, why we are using this “feature” in the first place, to reduce the band which necessary, to improve the parsing for the client?
To reduce the band which, gzip compression is the better choice. the price to reduce the work for the client is paid by the server, so not really a good deal.

So in my opinion we should consider the following.

  1. remove the feature from the admin
  2. add a warning that it will not work in any case and people should consider to use gzip instead

I’m in favor of option #2

Micha

On Wed, Jul 1, 2015 at 4:21 PM, Harry Klein <@Harry_Kleinmailto:Harry_Klein> wrote:
Should Lucee really remove whitespace in form field values, if this setting is active?
“Smart whitespace management - every whitespace character that follows a whitespace is removed, but whitespace inside the tags: ,

 and  is kept”

One of our customers reported a bug – he had problems to upload files with multiple spaces into our CMS.
The reason was this setting – the form value for this file e.g. “test spaces.jpg”, was stripped to “test spaces.jpg”.

-Harry

You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.commailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.commailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/F5A941E045A6FE4288ABB2E3D797146FA73B8246%40SRV-DC1.contens.localhttps://groups.google.com/d/msgid/lucee/F5A941E045A6FE4288ABB2E3D797146FA73B8246%40SRV-DC1.contens.local?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.commailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.commailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEByVoPVbNVCF6%2B5TrsT%2BUAbRX62GoF1RkBq95_H6%2B-U3Vw%40mail.gmail.comhttps://groups.google.com/d/msgid/lucee/CAG%2BEEByVoPVbNVCF6%2B5TrsT%2BUAbRX62GoF1RkBq95_H6%2B-U3Vw%40mail.gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout.

A quick question: I’m trying to achieve a similar something,namely using Smart whitespacemanagement to reduce the whitespace going across the line to the end-user in a webapp. But I want to preserver whitespace and carriage returns in certain files that are being generated. This is because the spaces are important as a measure where content is situated and where the next part of the content begins. Fixed length blocks so to say. Is there a way to preserver the carriage returns? I’ve “fooled” Lucee by adding a

-tag around the CFML, hence preservering the whitespace, but carriage returns are still being removed.

  1. To make it easier to read page source, as a developer, and correlate it back to CF code
  2. To fix issues with old browsers (IE 6 comes to mind) where whitespace in resultant HTML causes rendering issues.
  3. To reduce the size of pages browsers in limited memory/resource environment need to work with.

I suppose 4 and 5 are specific examples of your second case.

We’ve never had any problem with the whitespace setting ACF, which leads me to believe Lucee’s implementation isn’t being safe enough, or is removing things it shouldn’t. If Lucee is going to support that, then the answer to the bug report shouldn’t be “Remove the feature”

IMHO the bulk of whitespace removal should happen at the parsing stage, in between tags. (not just CF tags but HTML tags as well) Not inside tags, attributes, and form values. Similarly it shouldn’t touch content between textarea tags.

In absence of whitespace management (to fix #4) we’ve dealt with it like this

<div
  ><span class="blah"
    >This is the content of my span</span
    ></div
>

Which doesn’t prevent TRANSMISSION of whitespace, it just prevents the browser interpreting it as something it should display… Or

<div><!---
  ---><span class="blah"><!---
    --->This is the content of my span<!---
  ---></span><!---
---></div>

Which prevents both.

IMHO both of the abolve solutions look god-awful, but there are places where we had to do it.

CFScript supporters will no doubt indicate that explicitly using writeoutput() with strings eliminates most of the issue because the space between lines of code is removed - space in cfscript is removed at compile time and wouldn’t output anyway. But I don’t think doing the above with writeoutput looks any better. (Nor do I think whitespace needs to be removed within writeoutput) . And doing tag-like things in a script-like syntax makes my skin crawl too.

And sure, if we’re merely talking about bandwidth, gzip or brotli could be the way to go, but they also have performance issues as cycles will be taken to do the compression, plus they require browser support (which most do, but think also of dumber scripts, urllib, perl, curl, etc), and still when you view source, all that whitespace will be there - it was dutifully decompressed and reproduced in the page output. And a mobile browser that has to render a 32k page that is 50% whitespace is still overhead. Probably a dramatic example - but cfloops can very quickly multiply whitespace, especially if devs use spaces instead of tabs. (And really, should indentation style have a significant impact on size of a page? I think not)

I recently modified one of the whitespace management features on my version of Lucee to be a little more thorough.

In my code, this is common pattern:

<cffunction>
<cfargument>
<cfscript>
return "something";

I made it so the white space is removed all the way to the cfscript tag, instead of just between cffunction and cfargument at just the top so that I don’t need to use output=“no” to silence the whitespace. There is a some overhead to using output=“no” on the function tag, so I did this to make it have less overhead to achieve the same result of no whitespace. I like using tags for function definitions because of how easy it is to search for them with the quotes.

So currently Lucee filters the output at the end of a request. I think you were suggesting that the parser/compiler could make some of these whitespace decisions and have new features without adding any runtime overhead. That does sound like a good idea, since my first reaction to it how it works now was - woah that looks like a lot of code that might have a little overhead to it. I’m not sure if I’ll get around to making this feature work at the parser level, but I’m going to make a note of the idea.

For example, it’s probably safe to trim() the body of CFML loop/control flow and then add 1 space back to both sides, but only if there was at least 1 whitespace character there to begin with.

|<cfif true>
     Until Here
</cfif>|

Would output like | Until Here |

and
|<cfif true>Something</cfif>|

would output like |Something|

Perhaps, it could even reduce indentation of multiline literals by one as well automatically with a simple regex, so then the html would look prettified and all those form field / textarea / pre tag issues shouldn’t be a problem.

It’s worth mentioned that chrome dev tools indents your source code automatically, and gzip is always worth using even if you use this feature. The main issue here is how bad whitespace can get with tag based code. I just don’t want that to show in our source.

I am doing a lot of things with the parser/compiler in the future. Like what if Lucee had features that could rewrite our code or generate boilerplate in order to automatically support new features, beautify code, and run faster. I might make a way for Lucee to render the CFML back out as a formatted string which would allow creating code style transformations and feature transformations to existing code faster. This could also be used to validate and annotate code in different ways.