great if fixes/enhancements in the area of whitespace handling finds its way into 1.5. (I'm still working with very old versions of Vel, since nothing important has changed; I would only move to a new version if the whitespace handling has been fixed properly).
A bit more embedded below...
Nathan Bubna wrote:
[snip]
thus, i'd also be fine with having 1.5 *eliminate all* whitespace gobbling
by default (with filters optional)
*ugh* see your own statement below.
> and accept a formal syntax for directives
(e.g. #{if}foo#{else}bar#{end}woogie). these also *may* "break" things for
a small minority, but *will* ease frequent problems/confusions for most.
[snip]
In another mail in this thread Nathan Bubna wrote:
[snip]
> personally, i think it's a "flaw" to gobble any whitespace outside of > directives or method calls on a variable (a.k.a. whitespace in the schmoo > stays untouched). :-) it may not be optimal for having both pretty output > and pretty code, but it is by far the most intuitive way to go. no complex > or debatable rules to be figured out, just a simple "what you type (non-VTL) > is what you get" policy.
+1 Only thing to add here is: where do you set the limits of VTL. I proposed in the past to see standalone VTL (directives that have only whitespaces around them) to include the surrounding whitespaces. This means, that if I markup existing (text) schmoo I just need to add new VTL lines and all schmoo remains untouched. Or I insert VTL within a schmoo line and again all remains the same...
> > this is tied to my opinion that all whitespace ought to be treated equally > with the obvious exception of the line break closing a single line comment, > thus allowing multi-line directives, method calls, etc.
+1 ... if the VTL boundary issue is also clear ...
-- :) Christoph Reck
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
