Wow. That is quite some request. It actually seems closer to the TRIM directive than it does the CHOMP - but it is different from that also. Essentially it is a TRIM every TAG, but only the whitespace on the same line, and only if the TAG returned an empty string.
Looking at the internals - I don't think that this would be very feasible without performance hit. It would be dynamically changing the string appended to $output in the executed perl depending upon the return value of the TAG. The reason the pre and post chomp things work now is because they are independent of what is in the directive TAG and can modify the parsed and stored text during the compilation process. This request is asking that to happen later which is why I said it is closer to the TRIM directive - which happens later. Though it is theoretically possible to add this, it would introduce a performance hit for every directive call (I guess it would just be an if check - but there already would be many). As this seems to be a fairly limited use case, I'd go with the post processing method you have, but you could extended it to put a "# generated" tag at the end of any line that may have been generated. You could then remove lines that match "^\s*# generated" and you could cleanup other lines by removing "\s*# generated" from every line. It seems if you are trying to generate a good looking configuration file, that you would already have problems with indentation of items that return multiple lines (I guess you could pass them to | indent ). I can see the benefit of what you are proposing because I have had similar situations, but in almost all of them my work around was to chomp everything - but then include the proper indentation in the text returned by TAG (if any). I'm sure this isn't quite what you were looking for, but I'd thought I'd chip in my 2 cents. Paul > Here's another approach to my request: > > The basic idea is perhaps the opposite of the recent discussion. > My goal is *minimal* "chomping" , namely: > - If the white space is part of the text, keep it. > - But if a blank line was generated entirely by the TT markup, drop it. > > Most important in this is that text that originated from separate lines > should remain on separate lines. The motivation is the use of TT to > generate Apache configurations that are generated centrally and distributed > to the live Apache servers: > - I have to be careful about joining lines because line breaks matter > in the application. > - I want to keep indentation and intentional blank lines, while discarding > spurious blank lines, because that makes the output file easier to > eye-ball, which I occasionally do in addition to feeding the file > to Apache. > > It seems to me that CHOMPing operates at a token level, while what I > have in mind is more line-oriented: > (1) If the source line is empty or all white-space, keep it. > (2) If the expanded line is empty or all white-space, but the source > was not (ie contained TT markup), drop it. > (3) Keep everything else as is. > > I am now working around this by: > - Turning off all CHOMPing > - Using '#' to get as close as I can to a blank line, where I want that. > - Removing empty and blank lines from the final TT output > > My workaround cannot do exactly as I want, since a post-processor can't > distinguish cases (1) and (2). It would also be nice not to require > an extra pass through the data for the post-processing. > > So my request boils down to an option something like > "NO_GENERATED_BLANK_LINES" but preferrably with a shorter name. > > Does this make sense? Is it of interest to anyone else? > > Thanks, > > -Len Weisberg > > _______________________________________________ > templates mailing list > [email protected] > http://lists.template-toolkit.org/mailman/listinfo/templates _______________________________________________ templates mailing list [email protected] http://lists.template-toolkit.org/mailman/listinfo/templates
