Dominique Devienne wrote:
unless someone comes up with a good reason
why this is a bug rather than a feature.
It's a bug if it doesn't prefix that line with [echo] in non-emacs mode.
<echo/> is not much different from <echo>${foo}</echo> with foo being
empty. If foo is empty by mistake, how will one troubleshoot this?
Sure, not a very good example, but still. Any task output should be
prefixed with the task name in non-emacs mode. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This is the sort of input I wanted before I went off blindly changing
documentation to match current behavior.
But your example isn't quite correct either.
<echo>${foo}</echo> (with foo not defined)
will produce
[echo] ${foo}
and not a blank line. Undefined properties are echoed as literal text, not
skipped.
So, although the omission of the task tag may be unintended, I don't see it as
quite as bad a thing as you do. It is handy to be able to emit a totally blank
line. Although, to be perfectly consistent, we should probably define something
like <echo blank="true"/> or some such to get that behavior rather than this
accidental thing.
My feeling for now is to simply update the doc to say (on echo.html, for the
"required" column of the message attribute):
"No. Text may also be included in a character section within this element. If
neither is included a blank line will be emitted in the output."
leaving the question of the missing task label to be disposed of separately.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
