Closed GoogleCodeExporter closed 8 years ago
Thanks for the suggestion.
I've had something similar implemented already (unintentionally), but it was
reported as a bug which I fixed, as it produced inconsistent compression
results on Linux and Windows because \n is recognized as a new line character
only on *nix, on Windows it is \r\n.
In your first paragraph you said it would make code more readable, but at the
end you said "Humans are not the intended target of this application". Then who
is?
I am not sure if code readability is something I need to worry about. If you
look at any javascript compressor, they produce very hard to read one-liner,
and it is kind of the whole point.
Usually if I need to check something in a compressed HTML I just use browser's
developer tools which show html as a dom tree. There are also html beautifiers
out there.
Original comment by serg472@gmail.com
on 27 Jun 2011 at 5:40
> \n is recognized as a new line character only on *nix, on Windows it is \r\n.
This is mostly what I was getting at with point 1. However, most
editors/viewers I have used recognise the alternative newline sequences
regardless of platform - the only exception that comes to mind is Notepad.
Perhaps if the feature were to be implemented, the newline sequence could be
configurable. Allowing multiple character newlines such as \r\n would result in
suboptimal compression though.
> In your first paragraph you said it would make code more readable, but at the
end you said "Humans are not the intended target of this application". Then who
is?
>
> I am not sure if code readability is something I need to worry about. If you
look at any javascript compressor, they produce very hard to read one-liner,
and it is kind of the whole point.
The point of this feature would be to make code more readable, but I was
explicitly noting that readability is obviously not a primary concern for the
project. The benefits probably do not outweigh the cost if it is non-trivial to
implement.
If it *was* sanely implementable, I think it would be a useful optional
feature. Looking at the first example, the result with line feeds follows the
principle of least surprise (in my opinion).
Original comment by al.barr...@gmail.com
on 27 Jun 2011 at 6:06
Ok, I will add it to my todo list.
Original comment by serg472@gmail.com
on 27 Jun 2011 at 6:29
well I don't think that feature would be very popular. I wouldn't use that
feature ever. It is useful for debug purpose but in this case you can just
disable compression. So I guess the implementation of this feature depends on
the feature popularity. Or someone can contribute and develop that (like I did
for maven migration - I just need that so I contribute) :)
Original comment by alextu...@gmail.com
on 30 Jun 2011 at 8:14
Added in 1.4 release.
Command line compressor has --preserve-line-breaks option.
Java API has setPreserveLineBreaks(true) method.
It preserves original line breaks in the document (multiple breaks are
collapsed). So when compressing such document:
a\r\n\r\n\r\n
b\n\n\n
c
the result will be:
a\r\n
b\n
c
Thanks.
Original comment by serg472@gmail.com
on 8 Jul 2011 at 10:43
Original issue reported on code.google.com by
al.barr...@gmail.com
on 27 Jun 2011 at 4:06