On Sun, Feb 22, 2004 at 08:31:58PM -0500, James Gibbs wrote: > Aren't you the one complaining about the spaces on the left margin in > heredocs? I'm not trying to be critical, I'm just trying to understand > the issue. They are bad, right?
I'mm not complaining about leading whitespace itself, but only a .info syntax where that whitespace is *the* indicator for a multiline field. Here's a bunch of detail (i.e., "warning...long") on what (to the best of my knowledge) is going on now and what my concern is. There are two entirely different syntaxes for multiline fields: RFC-822 style: >PatchScript: perl -pi.BAK -e "s/VERSION = '0.39'/VERSION = '%v'/" ProcessTable.pm > cp -f ../Proc-ProcessTable-Darwin-04/os/* os So-called "here-doc" notation: >PatchScript: << > perl -pi.BAK -e "s/VERSION = '0.39'/VERSION = '%v'/" ProcessTable.pm > cp -f ../Proc-ProcessTable-Darwin-04/os/* os ><< RFC-822 says the first line of the field is on the line with the fieldname, and continues for all successive lines that are whitespace-indented. The RFC specifies "whitespace", not any particular amount nor even that the whitespace used must be consistent line-to-line. Since fink has to disregard all leading whitespace in this format, a language like python (as Rohan seems itching to use:) that uses indentation to indicate code blocks could not be used. Here-doc notation is indicated by the << on the first line. The actual field value begins on the next line, and continues up until (but not including) the line with << by itself. Within these delimeters, whitespace is irrelevant to the parsing of the field itself, so one could use it in a way that is meaningful to the field contents (e.g., python script). Or if leading whitespace has no meaning to the field contents, one can add it arbitrarily to make the .info file easier to read. The goal is to allow a Maintainer to construct a .info where leading whitespace can be meaningful. So you say: why not just accept either syntax, but tell people that python (etc.) can only be used with here-doc? The answer is that fink has to support nested multilining. And if one of those multiline fields is a SplitOff or InfoN[*], well the whole field is just a mini-package. Which means we now have a package description that is probably entirely indented. If it's RFC-822, we *have* to strip off all leading whitespace. That means a within a SplitOff we cannot use RFC-822 multiline at all, nor could we use python even if it were multilined in a heredoc. If the splitoff is a heredoc, all lines are usually indented (to keep the Maintainer from going cross-eyed). Since we're trying to allow meaningful whitespace, we don't strip it off. But that means every line is an RFC-822 continuation...the specification does not allow (nor is there a awy to intelligently parse) lines that are indented but "look like" the start of a new field. So if we want to handle meaningful whitespace in nested multiline fields, I cannot see how we can continue to allow RFC-822 syntax. [*] The InfoN field was introducted to allow us to implement features in a future fink that involve adding things to a .info that makes the file not-parsable by an older fink. We simply stuff the whole ".info" in an Info2 field and only this new fink would know to look there (older fink would just skip this otherwise Package:-less .info). That means even "top-level" fields are really nested multiline fields. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
