velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: Whitespace, redux
Date Fri, 19 Apr 2002 12:45:48 GMT
On 4/19/02 4:20 AM, "Christoph Reck" <Christoph.Reck@dlr.de> wrote:

> "Geir Magnusson Jr." wrote:
>> 
>> On 4/16/02 1:18 PM, "Christoph Reck" <Christoph.Reck@dlr.de> wrote:
>> 
>>> 
>>> Anyone (within those thousands of eyes and brains) out there sees soemthing
>>> wrong with my proposed (update of Daniel Dekany proposal):
>>> 
>>> If a line is looks like this:
>>> DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
>>> TabsAndSpaces ::= (#x20 | #x09)+
>>> LineEnd       ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
>>> then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd"
>>> should be gobbled. (Note that it supports multiline directives, that is
>>> why "DirectiveLine" is not simply "Line".) If you whant the first
>>> "LineEnd" to be gobbled prepend a ## before it (it is part of the
>>> previous line!).
>>> 
>>> I guess this is the nearest we can get a perfect solution.
>> 
>> I seem to be on the path to having this work, sort of.  I'll post a jar that
>> does this soon so we can play and decide if we really want to do this.  I
>> still don't think we want to.
> 
> Great! 
> (but for some weeks I won't be able to test it, busy with Swing application
> - anyway I'll be using it in the future, it is an important issue and thats
> why I'm taking the trouble to find a proper solution. For my past 4 velocity
> applications I used the comment-escaping and indenting workaround).

And for my past 'N' major projects involving velocity, I didn't have to do
squat...
 
>> 
>>> 
>>> It has a *very* small (but defined) impact on existing templates:
>>> existing standalone directives will gobble leading whitespaces
>>> (currently they gobble trailing whitespaces).
>>> This does not make things more convoluted, but makes it simpler
>>> and orthogonal.
>> 
>> Not sure I agree with the last sentence...  I am not sure I even understand
>> the last sentence.
> 
> Orthogonal means right-angled, so same in both directions.
> In velocity: I'm referring that it acts the same in both directions -
> gobble not only trailing whitespaces but handle leading ones also
> equally.

Hm - if something is orthogonal, it means that it's different - it goes in a
completely different direction.  In terms of some kind of decomposition to
basis vectors, two orthogonal vectors share nothing in common...

> 
> Orthogonal color components means that the 3 colors are at right angle
> in a 3D space; changing a component value does not affect the others
> - e.g. RGB, HSV, etc.
> In this sense, changing the whitespace handling in velocity should not
> affect other (velocity-) functionality.
> 
> Orthogonal command set in a CPU means that a command can be applied
> to any operand and register. This was the great improvement of a
> 68000 (early MAC) and RISC vs. Intel and other CPUs. An "add" could
> be done on any two registers, not only with the accumulator. A
> pre/post-increment after any operation with any register, not only
> with the counter register, etc.
> In velocity: the whitespace handling should be the same for EVERY
> directive, not different for an #end, #set, #parse, etc.
> 
> With orthogonal I mean "describe once and use/apply everywhere in a
> symmetrical form". KISS and you know what you will get.
> 
> Does this make sense now?

I think you might have meant to say 'symmetric' or 'internally
self-consistent'...

:)


-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting
The obvious solutions are challenging


--
To unsubscribe, e-mail:   <mailto:velocity-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:velocity-user-help@jakarta.apache.org>


Mime
View raw message