From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,8143b93889fe9472
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.180.89.133 with SMTP id bo5mr2360534wib.6.1359629817388;
        Thu, 31 Jan 2013 02:56:57 -0800 (PST)
Path: 
 i11ni30966wiw.0!nntp.google.com!proxad.net!feeder1-2.proxad.net!newsfeed.straub-nv.de!uucp.gnuu.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Thu, 31 Jan 2013 11:56:59 +0100
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Ada standard and maximum line lengths
References: <8dfcf819-e1d0-4578-a795-a4bf724b5014@googlegroups.com>
 <ke55qi$59m$1@dont-email.me> <ammppjF63goU1@mid.individual.net>
 <ke69q3$vou$1@dont-email.me> <amo50dFg605U1@mid.individual.net>
 <ke6o2n$jrj$1@dont-email.me> <amo8u2Fh3ngU1@mid.individual.net>
 <ke7peh$tof$1@dont-email.me> <ampmcqFqh9aU1@mid.individual.net>
 <5107b329$0$6556$9b4e6d93@newsspool4.arcor-online.net>
 <amptotFs5ouU1@mid.individual.net>
 <5107eaed$0$6566$9b4e6d93@newsspool4.arcor-online.net>
 <amqdeeF1b3qU1@mid.individual.net>
 <51080c38$0$6561$9b4e6d93@newsspool4.arcor-online.net>
 <amqnmtF3q45U1@mid.individual.net>
 <51085776$0$6637$9b4e6d93@newsspool2.arcor-online.net>
 <ams6reFdfsdU1@mid.individual.net> <wccfw1iheq9.fsf@shell01.TheWorld.com>
 <keca2j$uha$1@munin.nbi.dk> <wccwquucd1x.fsf@shell01.TheWorld.com>
 <alpine.DEB.2.02.1301310939580.17341@debian>
 <amurtjF1babU1@mid.individual.net>
In-Reply-To: <amurtjF1babU1@mid.individual.net>
Message-ID: <510a4df8$0$6549$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 31 Jan 2013 11:56:57 CET
NNTP-Posting-Host: 0590cb52.newsspool4.arcor-online.net
X-Trace: 
 DXC=l?B6KlNmkhNI7\_^6>c20J4IUK<Cl32<A4Fo<]lROoRA8kF<OcfhCOKLUi?h0ZgaZCnc\616M64>JLh>_cHTX3jMbJWbMN6OYjC
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2013-01-31T11:56:57+01:00
List-Id: <comp.lang.ada>

On 31.01.13 10:30, Niklas Holsti wrote:
> In practice, when one is developing a program that generates source-code
> (in Ada or other languages), it is often necessary to look at the output
> to check that it is correct, or to understand why it is wrong, and this
> is much easier if the output is not only broken into lines, but also
> indented in the usual way.

Google's Javascript -> Javascript compiler works this way.

It has options whose effects include the following instructions
obeyed by the compiler. (For reasons of style, the options
are named differently, and obfuscation is subsumed under "renaming
symbols" and "compressing output", referring to pretty printing
and optimizing.)

2) just obfuscate
3) obfuscate and remove most white space from lines
4) obfuscate and remove most white space including line endings

Option 4) is very popular.

Option 2) is the second most useful one for finding and reporting
errors, because finding locations will not require the assistance
of a "Javalisp system". (Google is working on a new "Inspector"
to be built into browsers, which features source code mapping.)