velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: Whitespace, redux
Date Wed, 17 Apr 2002 20:49:46 GMT
On 4/16/02 1:18 PM, "Christoph Reck" <> 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.
> 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.
> Geir, for character stream users that cannot predict if important
> spaces will follow a NL, they should just put a #**# upfront any
> directive to inhibit gobbling.

I really wouldn't advocate that as a solution to anyone...  It's just
downright bizarre...  The problem is that streams tend to be mechanically
generated - you might get content from some news feed (ok, that wouldn't be
marked up...) but you also might produce content mechanically from XSLT or
DVSL or something. I have a client that produces 'velocitized' content this
way, and believe that others must too....

>>> Again back to my proposal for the enhancing of the whitespace
>>> handling rules to do what a designer expects. Geir, is there
>>> a reason for a no-go?
>> We keep going through this - am I forgetting something?  (The last few weeks
>> have been fairly exhausting...)
> Geir, I don't know how many (Jakarta + others) lists you are
> subscribed, but the commons-list is saturating enough!

Only in bursts, it seems, and I always seem to wind up on the losing end...

> I don't see you forgetting anything, but I'm pointing out that my
> proposal is just getting responses that are "beating around the bush"
> without getting anywhere.

I don't understand this sentence.

> Only the #output(true|false|"hold") thread
> raised another possible approach, but as others stated it does not
> solve the problem of proper whitespace handling and can get to be a
> PITA when doing structured constructs in templates.

I'll take issue with the phrase 'proper whitespace handling' as I think the
definition of 'proper' is what we are arguing about.

I agree that #output() would be a PITA for certain things, but it certainly
is a nice way to solve a whole raft of issues, including removing whole
blocks of code for debugging.
> I'm trying to obtain a consensus to resolve velocitys stray whitespace
> problem. 
> Herewith I'm requesting everyone that sees *real* problems with the
> proposal should yell up. Others that second my proposal should vote
> a +1 even though they are not committers (nope - this should not
> lead to a revolution to the jakarta rules).

Getting a sense of what people want is the right thing.  I am not really
sure that what you want is the Right Thing - but I am trying it to see how
it will work...

Geir Magnusson Jr.                           
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message